[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45A5DE7C.3030108@redhat.com>
Date: Thu, 11 Jan 2007 01:51:40 -0500
From: Rik van Riel <riel@...hat.com>
To: yunfeng zhang <zyf.zeroos@...il.com>
CC: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.16.29 1/1] MM: enhance Linux swap subsystem
yunfeng zhang wrote:
> My patch is based on my new idea to Linux swap subsystem, you can find
> more in
> Documentation/vm_pps.txt which isn't only patch illustration but also file
> changelog. In brief, SwapDaemon should scan and reclaim pages on
> UserSpace::vmalist other than current zone::active/inactive. The change
> will conspicuously enhance swap subsystem performance by
Have you actually measured this?
If your measurements saw any performance gains, with what kind
of workload did they happen, how big were they and how do you
explain those performance gains?
How do you balance scanning the private memory with taking
pages off the per-zone page lists?
How do you deal with systems where some zones are really
large and other zones are really small, eg. a 32 bit system
with one 880MB zone and one 15.1GB zone?
If the benefits come mostly from better IO clustering, would
it not be safer/less invasive to add swapout clustering of the
same style that the BSD kernels have?
For your reference, the BSD kernels do swapout clustering like this:
1) select a page off the end of the pageout list
2) then scan the page table the page is in, to find
nearby pages that are also eligable for pageout
3) page them all out with one disk I/O operation
The same could also be done for files.
With peterz's dirty tracking (and possible dirty limiting)
code in the kernel, this can be done without the kind of
deadlocks that would have plagued earlier kernels, when
trying to do IO trickery from the pageout path...
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists