From: Robert Love <rml@tech9.net>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-mm@kvack.org, kernelnewbies@nl.linux.org,
linux-kernel@vger.kernel.org
Subject: Re: [CFT][PATCH *] faster cache reclaim
Date: 09 Oct 2001 19:29:13 -0400 [thread overview]
Message-ID: <1002670160.862.15.camel@phantasy> (raw)
In-Reply-To: <Pine.LNX.4.33L.0110082032070.26495-100000@duckman.distro.conectiva>
In-Reply-To: <Pine.LNX.4.33L.0110082032070.26495-100000@duckman.distro.conectiva>
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
WARNING: multiple messages have this Message-ID (diff)
From: Robert Love <rml@tech9.net>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-mm@kvack.org, kernelnewbies@nl.linux.org,
linux-kernel@vger.kernel.org
Subject: Re: [CFT][PATCH *] faster cache reclaim
Date: 09 Oct 2001 19:29:13 -0400 [thread overview]
Message-ID: <1002670160.862.15.camel@phantasy> (raw)
In-Reply-To: <Pine.LNX.4.33L.0110082032070.26495-100000@duckman.distro.conectiva>
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/
next prev parent reply other threads:[~2001-10-09 23:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-08 23:38 [CFT][PATCH *] faster cache reclaim Rik van Riel
2001-10-08 23:38 ` Rik van Riel
2001-10-09 1:28 ` Bill Huey
2001-10-09 1:28 ` Bill Huey
2001-10-09 23:29 ` Robert Love [this message]
2001-10-09 23:29 ` Robert Love
2001-10-10 2:04 ` Bill Huey
2001-10-10 2:04 ` Bill Huey
2001-10-09 23:49 ` Krishnakumar B
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1002670160.862.15.camel@phantasy \
--to=rml@tech9.net \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.