lkml.org 
[lkml]   [2006]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [PATCH] mm: moving dirty pages balancing to pdfludh entirely
Date
From
Nikita Danilov wtites:
>> Pdflush thread functions as before patching. Pdflush tends to make
pages
>> un-dirty without overload memory or IO and it is not need to let
pdflush

> This assumption is valid for ext2

The assumption that pdflush should to make pages un-dirty without
overload memory or IO is not for ext2 but for it sense. I'm working with
ext3. A lot of work it does while writepages(). pdflush is throttled:
while vmscan have sorted 32 page for paging-out it calls
blk_congestion_wait() nevertheless had it put one of 32 page into
congested queue or had not. pdflush is throttled.

Leonid


-----Original Message-----
From: Nikita Danilov [mailto:nikita@clusterfs.com]
Sent: Tuesday, July 04, 2006 1:55 PM
To: Ananiev, Leonid I
Cc: Linux Kernel Mailing List
Subject: Re: [PATCH] mm: moving dirty pages balancing to pdfludh
entirely

Ananiev, Leonid I writes:
> Nikita Danilov wtites:
> > performs page-out even if queue is congested.
> Yes. If user thread which generates dirty pages need in
> reclaimed memory it consider own dirty page as candidate for
page-out.
> It functions as before patching.
>
> > Intent of this is to throttle writers.
> I suppose you means dirtier or write(2) caller but not writepage()
> caller. The dirtier is throttled with backing_dev_info logic as
before
> patching.

I meant ->writepages() used by balance_dirty_pages(), see below.

>
> While pdflush thread sorts pages for page-out it does not
> consider as a candidate a page to be written with congested queue.
> Pdflush thread functions as before patching. Pdflush tends to make
pages
> un-dirty without overload memory or IO and it is not need to let
pdflush

This assumption is valid for ext2, where ->writepages() simply sends
pages to the storage, but other file systems (like reiser4) do a *lot*
of work in ->writepages() path, allocating quite an amount of memory
before starting write-out. With your patch, this work is done from
pdflush, and won't be throttled by may_write_to_queue() check, thus
increasing a risk of allocation failure.

> do page-out with congested queue as you have proposed.
>
> Leonid

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-04 13:45    [W:0.044 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site