Re: [PATCH] modified segq for 2.5

[Andrew Morton <akpm@digeo.com>]

Ed Tomlinson wrote:
> 
> On September 9, 2002 05:38 am, Andrew Morton wrote:
> 
> > With nonblocking-vm and slabasap, the test took 150 seconds.
> > Removing slabasap took it down to 98 seconds.  The slab rework
> > seemed to leave an extra megabyte average in cache.  Which is not
> > to say that the algorithms in there are wrong, but perhaps we should
> > push it a bit harder if there's swapout pressure.
> 
> Andrew, One simple change that will make slabasap try harder is to
> use only inactive pages caculating the ratio.
> 
> unsigned int nr_used_zone_pages(void)
> {
>         unsigned int pages = 0;
>         struct zone *zone;
> 
>         for_each_zone(zone)
>                 pages += zone->nr_inactive;
> 
>         return pages;
> }
> 
> This will make it closer to slablru which used the inactive list.

hmm.  Well if we are to be honest to the "account for seeks" thing
then perhaps we should double-count for swap activity - a swapout
and a swapin is two units of seekiness.  So consider add_to_swap()
to be worth two page scans.  Maybe the same for swap_writepage().

That should increase pressure on slab when anon pages are being
victimised.  Ditto for dirty MAP_SHARED I guess.

> Second item.  Do you run gkrelmon when doing your tests?  If not please
> install it and watch it slowly start to eat resources.   This morning (uptime
> 12hr) it was using 31% of CPU.  Stopping and starting it did not change this.
> Think we have something we can improve here.  I have inclued an strace
> of one (and a bit) update cycle.

I was running gkrellm for a while.  Is that the same thing?  I didn't
see anything untoward in there.  It seems to update at 10Hz or more,
so it's fairly expensive.  But no obvious increase in load across time.

It seems that the CPU load accounting in 2.5 is a bit odd; perhaps
as a result of the HZ changes.  Certainly it is hard to make comparisons
with 2.4 based upon it.  Probably one needs to equalise the HZ settings
to make useful comparison.

Anyway.  Could you please run the kernel profiler, see where the time
is being spent?  Just add `profile=1' to the kernel boot line and
use this:

readprofile -r
sleep 30
readprofile -v -m /boot/System.map | sort -n +2 | tail -40

(If readprofile screws up, edit your System.map and remove all
the lines containing " w " and " W ")
--
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/