Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
newsfeed.mesh.ad.jp!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <[email protected]>
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Original-Date: Sun, 10 Jun 2001 01:40:44 -0300 (BRST)
From: Rik van Riel <[email protected]>
X-X-Sender: <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Subject: [PATCH] 2.4.6-pre2 page_launder() improvements
Original-Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk
X-Mailing-List: [email protected]
Organization: Internet mailing list
Date: Sun, 10 Jun 2001 04:42:01 GMT
Message-ID: <[email protected]>
Lines: 271
[Request For Testers ... patch below]
Hi,
during my holidays I've written the following patch (forward-ported
to 2.4.6-pre2 and improved a tad today), which implements these
improvements to page_launder():
1) don't "roll over" inactive_dirty pages to the back of the
list, but reclaim them in something more resembling LRU
order; this is especially good when the system has tons
of inactive_dirty pages due to eg. background scanning
2) eliminate the infinite penalty clean pages had over dirty
pages by not scanning the complete inactive_dirty list and
letting real dirty pages build up near the front of the
list ... we flush them asynchronously when we have enough
of them
3) when going into the launder_loop, we scan a larger fraction
of the inactive_dirty list; under most workloads this means
we can always flush the dirty pages asynchronously because
we'll have clean, freeable pages in the part of the list we
only scan in the launder_loop
4) when we have only dirty pages and cannot free pages, we
remember this for the next run of page_launder() and won't
waste CPU by scanning pages without flushing them in the
launder loop (after maxlaunder goes negative)
5) this same logic is used to control when we use synchronous
IO; only when we cannot free any pages now do we wait on
IO, this stops kswapd CPU wastage under heavy write loads
6) the "sync" argument to page_launder() now means whether
we're _allowed_ to do synchronous IO or not ... page_launder()
is now smart enough to determine if we should use asynchronous
IO only or if we should wait on IO
This patch has given excellent results on my laptop and my
workstation here and seems to improve kernel behaviour in tests
quite a bit. I can play mp3's unbuffered during moderate write
loads or moderately heavy IO ;)
YMMV, please test it. If it works great for everybody I'd like
to get this improvement merged into the next -pre kernel.
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
Patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
nntp-relay.ihug.net!ihug.co.nz!news-hog.berkeley.edu!ucberkeley!
130.54.14.37.MISMATCH!newsfeed.media.kyoto-u.ac.jp!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <[email protected]>
From: "Alok K. Dhir" <[email protected]>
To: "'Rik van Riel'" <[email protected]>
Cc: <[email protected]>
Subject: RE: [PATCH] 2.4.6-pre2 page_launder() improvements
Original-Date: Wed, 13 Jun 2001 00:42:45 -0400
Original-Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <[email protected]>
Importance: Normal
Sender: [email protected]
Precedence: bulk
X-Mailing-List: [email protected]
Organization: Internet mailing list
Date: Wed, 13 Jun 2001 04:41:01 GMT
Message-ID: <[email protected]>
References: <[email protected]>
Lines: 320
Are these page_launder improvements included in 2.4.6-pre3? Linus
mentions "VM tuning has also happened" in the announcement - but there
doesn't seem to be mention of it in his list of changes from -pre2...
Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
newsfeed.mesh.ad.jp!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <[email protected]>
Original-Date: Wed, 13 Jun 2001 15:46:55 -0300 (BRT)
From: Marcelo Tosatti <[email protected]>
X-Sender: [email protected]
To: "Alok K. Dhir" <[email protected]>
Cc: "'Rik van Riel'" <[email protected]>, [email protected]
Subject: RE: [PATCH] 2.4.6-pre2 page_launder() improvements
In-Reply-To: <[email protected]>
Original-Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk
X-Mailing-List: [email protected]
Organization: Internet mailing list
Date: Wed, 13 Jun 2001 20:23:09 GMT
Message-ID: <[email protected]>
References: <[email protected]>
Lines: 16
On Wed, 13 Jun 2001, Alok K. Dhir wrote:
>
> Are these page_launder improvements included in 2.4.6-pre3? Linus
> mentions "VM tuning has also happened" in the announcement - but there
> doesn't seem to be mention of it in his list of changes from -pre2...
Yes, it is.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/