[CFT][PATCH *] faster cache reclaim

[CFT][PATCH *] faster cache reclaim

[Rik van Riel]

Hi,

after looking at some other things for a while, I made a patch to
get 2.4.10-ac* to correctly eat pages from the cache when it is
about pages belonging to files which aren't currently in use. This
should also give some of the benefits of use-once, but without the
flaw of not putting pressure on the working set when a streaming IO
load is going on.

It also reduces the distance between inactive_shortage and
inactive_plenty, so kswapd should spend much less time rolling
over pages from zones we're not interested in.

This patch is meant to fix the problems where heavy cache
activity flushes out pages from the working set, while still
allowing the cache to put some pressure on the working set.

I've only done a few tests with this patch, reports on how
different workloads are handled are very much welcome:

http://www.surriel.com/patches/2.4/2.4.10-ac9-eatcache

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [CFT][PATCH *] faster cache reclaim

[Bill Huey]

On Mon, Oct 08, 2001 at 08:38:27PM -0300, Rik van Riel wrote:
> It also reduces the distance between inactive_shortage and
> inactive_plenty, so kswapd should spend much less time rolling
> over pages from zones we're not interested in.
> 
> This patch is meant to fix the problems where heavy cache
> activity flushes out pages from the working set, while still
> allowing the cache to put some pressure on the working set.

Rik,

It work well when I pressure it under some intensive IO operations under
dpkg and made progress when previous VMs basically froze. I did have two
running programs that have large working sets which created a lot of
contention and some CPU choppiness, but possibly some per process thrash
control should allow for both to make progress. ;-)

Good work.

bill

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [CFT][PATCH *] faster cache reclaim

[Robert Love]

On Mon, 2001-10-08 at 19:38, Rik van Riel wrote:

> This patch is meant to fix the problems where heavy cache
> activity flushes out pages from the working set, while still
> allowing the cache to put some pressure on the working set.

Running 2.4.10-ac10 + preempt-kernel + eatcache

System with 3 runnable processes and 2 with large working sets.  384MB
RAM, 768MB swap.  During heavy I/O the resulting cache activity did
"stall" the system as badly as without the patch.

I typically notice high system response time at the start of a heavy I/O
operation when the used memory is primarily taken by cache (ie after a
previous heavy I/O operation).  This was an issue for me because I don't
expect that sort of high latency with the preemption patch.

For example, starting a `dbench 16' would sometimes cause a brief stall
(especially if it is the second run of dbench).  It's better now, but
still not perfect.  The VM holds a lot of locks for a long time.

Good work.  I hope Alan sees it soon.

	Robert Love

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [CFT][PATCH *] faster cache reclaim

[Bill Huey]

On Tue, Oct 09, 2001 at 07:29:13PM -0400, Robert Love wrote:
> For example, starting a `dbench 16' would sometimes cause a brief stall
> (especially if it is the second run of dbench).  It's better now, but
> still not perfect.  The VM holds a lot of locks for a long time.
> 
> Good work.  I hope Alan sees it soon.

Yeah, but overall the performance of his recent patch is pretty amazing.

It's really good that Linux is finally getting a VM that behaves well and
can keep the working set in memory without heavy IO activity flushing out
critical process pages. The performance of Riel's VM system should hold for
server activity too. And adding something like thrash control to help make
sure aging still works (without statistical scattering) under heavy load
should allow Riel's VM to progress under loads that would freeze previous VMs.

;-)

bill

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/