On Wed, 28 Aug 2002, Andrew Morton wrote:
> 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 ;)
I pull the NUMA-fallback card ;)
But serious, having one waitqueue for this case should be
fine. If the system is not under lots of VM pressure with
tons of dirty pages, kswapd will free pages as fast as
they get allocated.
If the system can't keep up and we have to wait for dirty
page writeout to finish before we can allocate more, it
shouldn't really matter how many waitqueues we have.
Except for the fact that having a more complex system can
introduce more opportunities for unfairness and starvation.
> > 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.
Yup, but if I were to wait for your queue to shrink I'd never get
any patches merged ;)
> 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.
I'll introduce this stuff in 2 or 3 steps, with descriptions.
> 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...
Eeeks ;) I don't even have a broad range of hardware...
regards,
Rik
-- Bravely reimplemented by the knights who say "NIH".http://www.surriel.com/ http://distro.conectiva.com/
- 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/
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:25 EST