Nikita Danilov writes:
> When queue is congested---it is, because meta-data (indirect blocks in
> ext[23] case) have to be read in synchronously before page can be
paged
> out (see comment in mm/vmscan.c:pageout()).
Actually a queue is congested ---it is, because the queue is too long or
bit BDI_write[read]_congested is set.
> But much more importantly: when direct reclaim skips writing dirty
pages
> from tail of the inactive list,
The direct reclaim does not skip any page in pdflush thread because
may_write_to_queue() returns true
if (current->flags & PF_SWAPWRITE) and: __pdflush() sets this flag:
See pfflush.c: __pdflush() first line
current->flags |= PF_FLUSHER | PF_SWAPWRITE;
> Wouldn't this interfere with current->backing_dev_info logic?
> Maybe pdflush threads should set this field too?
It is not need to set current->backing_dev_info for pdflush because
PF_SWAPWRITE is set for pdflush.
The proposed patch does not concern of backing_dev_info logic.
Leonid
-----Original Message-----
From: Nikita Danilov [mailto:[email protected]]
Sent: Tuesday, July 04, 2006 5:12 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 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.
When queue is congested---it is, because meta-data (indirect blocks in
ext[23] case) have to be read in synchronously before page can be paged
out (see comment in mm/vmscan.c:pageout()).
But much more importantly: when direct reclaim skips writing dirty pages
from tail of the inactive list, it instead moves these pages to the head
of this list, and reclaims clean pages instead. These clean pages are
"hotter" than skipped dirty pages, and as has been checked many times
already, this is bad, because doing reclaim in LRU order is important.
>
> 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]
