Hi,
04/25/2013 07:49 PM, Miklos Szeredi пишет:
On Thu, Apr 25, 2013 at 4:29 PM, Maxim V. Patlasov
<mpatlasov@xxxxxxxxxxxxx> wrote:
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 0713bfb..c47bcd4 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1235,7 +1235,8 @@ static void balance_dirty_pages(struct address_space
*mapping,
*/
nr_reclaimable = global_page_state(NR_FILE_DIRTY) +
global_page_state(NR_UNSTABLE_NFS);
- nr_dirty = nr_reclaimable +
global_page_state(NR_WRITEBACK);
+ nr_dirty = nr_reclaimable +
global_page_state(NR_WRITEBACK) +
+ global_page_state(NR_WRITEBACK_TEMP);
global_dirty_limits(&background_thresh, &dirty_thresh);
Please drop this patch. As we discussed in LSF/MM, the fix above is correct,
but it's not enough: we also need to ensure disregard of NR_WRITEBACK_TEMP
when balance_dirty_pages() is called from fuse daemon. I'll send a separate
patch-set soon.
Please elaborate. From a technical perspective "fuse daemon" is very
hard to define, so anything that relies on whether something came from
the fuse daemon or not is conceptually broken.
As Mel Gorman pointed out, fuse daemon diving into balance_dirty_pages
should not kick flusher judging on NR_WRITEBACK_TEMP. Essentially, all
we need in balance_dirty_pages is:
if (I'm not fuse daemon)
nr_dirty += global_page_state(NR_WRITEBACK_TEMP);
The way how to identify fuse daemon was not thoroughly scrutinized
during LSF/MM. Firstly, I thought it would be enough to set a
per-process flag handling fuse device open. But now I understand that
fuse daemon may be quite a complicated multi-threaded multi-process
construction. I'm going to add new FUSE_NOTIFY to allow fuse daemon
decide when it works on behalf of draining writeout-s. Having in mind
that fuse-lib is multi-threaded, I'm also going to inherit the flag on
copy_process(). Does it make sense for you?
Also, another patch will put this ad-hoc FUSE_NOTIFY under fusermount
control. This will prevent malicious unprivileged fuse mounts from
setting the flag for malicious purposes.
Thanks,
Maxim
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
