lkml.org 
[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] adjustments to dirty memory thresholds
Rik van Riel wrote:
>
> On Wed, 28 Aug 2002, Andrew Morton wrote:
>
> > But sigh. Pointlessly scanning zillions of dirty pages and doing
> > nothing with them is dumb. So much better to go for a FIFO snooze on a
> > per-zone waitqueue, be woken when some memory has been cleansed.
>
> But not per-zone, since many (most?) allocations can be satisfied
> from multiple zones. Guess what 2.4-rmap has had for ages ?

Per-classzone ;)

> Interested in a port for 2.5 on top of 2.5.32-mm2 ? ;)
>
> [I'll mercilessly increase your patch queue since it doesn't show
> any sign of ever shrinking anyway]

Lack of patches is not a huge problem at present ;). It's getting them
tested for performance, stability and general does-good-thingsness
which is the rate limiting step.

The next really significant design change in the queue is slablru,
and we'll need to let that sit in partial isolation for a while to
make sure that it's doing what we want it to do.

But yes, I'm interested in a port of the code, and in the description
of the problems which it solves, and how it solves them. But what is
even more valuable than the code is a report of its before-and-after
effectiveness under a broad range of loads on a broad range of
hardware. That's the most time-consuming part...
-
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: 2005-03-22 13:28    [W:1.516 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site