Nikita Danilov writes:
> 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.
....
After Nikita Danilov agrees that
> pdflush is throttled through blk_congestion_wait(), but it is not
> throttled by writing dirty from the tail of inactive list
The 'writing dirty from the tail of inactive list' is asynchronous
writing and it is not applicable for throttling.
Leonid
-----Original Message-----
From: Nikita Danilov [mailto:[email protected]]
Sent: Tuesday, July 04, 2006 3:56 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:
> >> 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
I am not sure what "sense" is being referred to. Some file systems do
allocate a lot of memory in ->writepages().
ext3 is still in the same ball-park as ext2.
> 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.
pdflush is throttled through blk_congestion_wait(), but it is not
throttled by writing dirty from the tail of inactive list, while
scanning for memory. This destroys LRU ordering.
>
> Leonid
>
Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]