search for: dirtied

Greetings All, Without going into the specific reasons why I need to do so, is anyone aware of a method (or tool) of watching real-time, human-readable (or system call print) of ext3 filesystem operations on a mounted, active filesystem? Excuse me if this is a duplicate question but I was unable to find any similar ones in the archives. Thanks in advance! Kevin Strong Criminal Information

From: Michel Dänzer <michel.daenzer at amd.com> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com> --- Chris / Ilia / Ben, this should be manageable for the intel/nouveau drivers, right? src/amdgpu_drv.h | 26 ++++++++++++++++++++++++++ src/amdgpu_kms.c | 18 +++++++++--------- src/drmmode_display.c | 8 ++++++-- 3 files changed, 41 insertions(+), 11 deletions(-)

From: Michel Dänzer <michel.daenzer at amd.com> This allows making the master screen's pixmap_dirty_list entries explicitly reflect that we're now tracking the root window instead of the screen pixmap, in order to allow Present page flipping on master outputs while there are active slave outputs. Define HAS_DIRTYTRACKING_DRAWABLE_SRC for drivers to check, but leave

Add hypercall (shadow op: enable/disable and clean/peek dirtied page bitmap). It consists of two parts: dirty page detecting and saving. For detecting, we setup the guest p2m''s leaf PTE read-only and whenever the guest tries to write something, permission fault happens and traps into xen. The permission-faulted GPA should be saved for the toolstack...

...) [xc_save]: /usr/lib/xen/bin/xc_save 28 1 0 0 1 [2008-06-11 12:18:19 3983] INFO (XendCheckpoint:349) Had 0 unexplained entries in p2m table [2008-06-11 12:24:01 3983] INFO (XendCheckpoint:349) Saving memory pages: iter 1 1: sent 61452, skipped 4084, delta 341840ms, dom0 15%, target 2%, sent 5Mb/s, dirtied 0Mb/s 8216 pages [2008-06-11 12:24:26 3983] INFO (XendCheckpoint:349) Saving memory pages: iter 2 2: sent 6720, skipped 1496, delta 24388ms, dom0 13%, target 5%, sent 9Mb/s, dirtied 2Mb/s 1841 pages [2008-06-11 12:24:30 3983] INFO (XendCheckpoint:349) Saving memory pages: iter 3 3: sent 1130, skipp...

...dirty bitmap. >>>> 5. The guest is being migrated by the host. The modified page is not >>>> being migrated. >>> >>> Whenever the guest modifies a page during migration, it will be >>> captured by the dirty logging and the hypervisor will send the dirtied the >> page in the following round. >> >> Please explain why the steps I outlined don't apply esp. in the last round. >> Your general statement does not explain why this race can't happen. >> > > The guest is stopped in the last round, thus no page will...

...dirty bitmap. >>>> 5. The guest is being migrated by the host. The modified page is not >>>> being migrated. >>> >>> Whenever the guest modifies a page during migration, it will be >>> captured by the dirty logging and the hypervisor will send the dirtied the >> page in the following round. >> >> Please explain why the steps I outlined don't apply esp. in the last round. >> Your general statement does not explain why this race can't happen. >> > > The guest is stopped in the last round, thus no page will...

Hello, I have two computers, one with Ubuntu 14.04 and one with Ubuntu 16.04. On both computers I have configured the printer with cups to print by using my Kerberos credential in the same way and it works in 14.04 but not on 16.04. For both /usr/bin/smbspool_krb5_wrapper is 700 and I have "AuthInfoRequired negotiate" for both in /etc/cups/printers.conf. I have made a symbolic link

Now that we have implemented systemd socket activation, we can use this to run qemu-nbd in tests. The first patch leaves some dead code around (the -DSERVE_OVER_TCP=1 path). It's possible we might want to use this to test against a putative future NBD server that only supports TCP, but on the other hand maybe we should just remove it. Tests & valgrind still pass for me. Rich.

>> 1. Guest allocates a page and sends it to the host. >> 2. Shrinker gets active and releases that page again. >> 3. Some user in the guest allocates and modifies that page. The dirty bit is >> set in the hypervisor. > > The bit will be set in KVM's bitmap, and will be synced to QEMU's bitmap when the next round starts. > >> 4. The host processes

>> 1. Guest allocates a page and sends it to the host. >> 2. Shrinker gets active and releases that page again. >> 3. Some user in the guest allocates and modifies that page. The dirty bit is >> set in the hypervisor. > > The bit will be set in KVM's bitmap, and will be synced to QEMU's bitmap when the next round starts. > >> 4. The host processes

Here''s a question about FE driver and log dirty, when live migration is concerned. Log dirty mode is used in live migration, which works for those polluted pages from CPU issued accesses, but not for DMA path (as BE driver talked here which access from another domain like dom0). Most frontend drivers don''t implement their own suspend interface (netfront implements when

...tion, these modified pages will > > be traced by the dirty page logging mechanism. So in the following > > migration_bitmap_sync() function. > > > > The pages in the free pages bitmap, but latter was modified, will be > > > > reset to dirty. We won't omit any dirtied pages. > > > > > > > > So, guest doesn't need to keep any free pages. > > > > > > OK, yes, that works; so we do: > > > * enable dirty logging > > > * ask guest for free pages > > > * initialise the migration bitmap as ev...

...tion, these modified pages will > > be traced by the dirty page logging mechanism. So in the following > > migration_bitmap_sync() function. > > > > The pages in the free pages bitmap, but latter was modified, will be > > > > reset to dirty. We won't omit any dirtied pages. > > > > > > > > So, guest doesn't need to keep any free pages. > > > > > > OK, yes, that works; so we do: > > > * enable dirty logging > > > * ask guest for free pages > > > * initialise the migration bitmap as ev...

...getting the free pages information, these modified pages will be traced > > by the dirty page logging mechanism. So in the following migration_bitmap_sync() function. > > The pages in the free pages bitmap, but latter was modified, will be reset to dirty. We won't > > omit any dirtied pages. > > > > So, guest doesn't need to keep any free pages. > > OK, yes, that works; so we do: > * enable dirty logging > * ask guest for free pages > * initialise the migration bitmap as everything-free > * then later we do the normal sync-dirty bitmap...

...getting the free pages information, these modified pages will be traced > > by the dirty page logging mechanism. So in the following migration_bitmap_sync() function. > > The pages in the free pages bitmap, but latter was modified, will be reset to dirty. We won't > > omit any dirtied pages. > > > > So, guest doesn't need to keep any free pages. > > OK, yes, that works; so we do: > * enable dirty logging > * ask guest for free pages > * initialise the migration bitmap as everything-free > * then later we do the normal sync-dirty bitmap...

...s the request and clears the bit in the dirty bitmap. >> 5. The guest is being migrated by the host. The modified page is not being >> migrated. > > Whenever the guest modifies a page during migration, it will be captured by the > dirty logging and the hypervisor will send the dirtied the page in the following round. Please explain why the steps I outlined don't apply esp. in the last round. Your general statement does not explain why this race can't happen. -- Thanks, David / dhildenb

...s the request and clears the bit in the dirty bitmap. >> 5. The guest is being migrated by the host. The modified page is not being >> migrated. > > Whenever the guest modifies a page during migration, it will be captured by the > dirty logging and the hypervisor will send the dirtied the page in the following round. Please explain why the steps I outlined don't apply esp. in the last round. Your general statement does not explain why this race can't happen. -- Thanks, David / dhildenb

This patch series silences some unknown cap warnings and fixes up coding style (patch 1+4). The most important part of this series are the two patches in the middle. They rework the state_fb code, so that we are able to render to not 64 byte aligned targets, as this is the only real use-case for render temporaries this allows us to drop temp code completely and simplifies a lot

Write dirty block groups may allocate new block, thus may add new delayed back ref. btrfs_run_delayed_refs may make some block groups dirty. commit_cowonly_roots does not handle the recursion properly, so some dirty blocks can be left unwritten at commit time. This patch move btrfs_run_delayed_refs into the loop that writes dirty block groups, and make the code not break out of the loop until