This adopts Rik van Riel's recent extended VM statistics patch for the
'armed-to-the-gills-kitchen-sink rmap' against 2.5.26. The aim, in
combination with a meaningful benchmark suite, is to be able to have the
statistical ammunition to fine tune the VM properly, rather than twiddling
all knobs at once hoping to make things better.
Get the patch series here:
http://loke.as.arizona.edu/~ckulesa/kernel/rmap-vm/2.5.26/
Rik's original announcement is here:
http://mail.nl.linux.org/linux-mm/2002-07/msg00172.html
and I have added Bill Irwin's alterations to the patch, described here:
http://www.cs.helsinki.fi/linux/linux-kernel/2002-28/1287.html
Given the late hour, I have almost certainly forgotten some hooks in
vmscan, so count it as a first, harmless cut at the problem. Feedback
and fixes welcome! :)
For 2.5.27, I'll make sure this patch is incremental to Rik's stats patch,
and not a replacement for it. Sorry 'bout that...
Craig Kulesa
Steward Observatory
Univ. of Arizona
This latest version takes advantage of the list management macros in
mm_inline.h to handle all of the 'pgactivate' and 'pgdeactivate'
counter incrementing. This simplifies the patch, and makes it easier to
keep accounting accurate.
http://loke.as.arizona.edu/~ckulesa/kernel/rmap-vm/2.5.26/
[ 2.5.26-rmap-6-VMstats2 19-Jul-2002 23:27 10k ]
Craig Kulesa
Steward Obs.
Univ. of Arizona
On Fri, 19 Jul 2002, Craig Kulesa wrote:
> This latest version takes advantage of the list management macros in
> mm_inline.h to handle all of the 'pgactivate' and 'pgdeactivate'
> counter incrementing. This simplifies the patch, and makes it easier to
> keep accounting accurate.
Except for the fact that you'll count every new page allocation
as an activation, which isn't quite the intended behaviour ;)
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Sat, 20 Jul 2002, Rik van Riel wrote:
> Except for the fact that you'll count every new page allocation
> as an activation, which isn't quite the intended behaviour ;)
*thwaps forehead* Ohhh, quite right. Darn. :)
Hmmm. Does it sound acceptable to still increment pgdeactivate in
mm_inline.h, and explicitly put hooks for pgactivate in the select places
where pages really _are_ being 'reactivated'? That sounds fairly sensible
to me -- unless you want to differentiate between pages that leave the
active list via drop_behind() versus deactivate_page_nolock().
Many thanks,
-Craig
On Sat, 20 Jul 2002, Craig Kulesa wrote:
> On Sat, 20 Jul 2002, Rik van Riel wrote:
>
> > Except for the fact that you'll count every new page allocation
> > as an activation, which isn't quite the intended behaviour ;)
>
> *thwaps forehead* Ohhh, quite right. Darn. :)
>
> Hmmm. Does it sound acceptable to still increment pgdeactivate in
> mm_inline.h, and explicitly put hooks for pgactivate in the select
> places where pages really _are_ being 'reactivated'?
Acceptable, sure ... but probably not worth it as Linus merged
the VM statistics into his tree yesterday afternoon.
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/