2.4.9-ac16 good perfomer?

2.4.9-ac16 good perfomer?

[Thomas Hood]

Either 2.4.9-ac16 has much improved VM performance over 
previous 2.4 kernels (under moderate load, at least), or someone
sneaked in to my apartment last night and upgraded my machine
while I was asleep.  I'm leaning toward the latter explanation.

--
Thomas

Re: 2.4.9-ac16 good perfomer?

[Rik van Riel]

On Thu, 27 Sep 2001, Thomas Hood wrote:

> Either 2.4.9-ac16 has much improved VM performance over
> previous 2.4 kernels (under moderate load, at least), or someone
> sneaked in to my apartment last night and upgraded my machine
> while I was asleep.  I'm leaning toward the latter explanation.

Now that the -ac VM was stable for a few weeks, I thought
it might be time to sneak in some big performance changes,
finally.

They seem to work ;)

cheers,

Rik
-- 
IA64: a worthy successor to i860.

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: 2.4.9-ac16 good perfomer?

[bill davidsen]

In article <Pine.LNX.4.33L.0109280049380.19147-100000@imladris.rielhome.conectiva>,
Rik van Riel <riel@conectiva.com.br> wrote:
| On Thu, 27 Sep 2001, Thomas Hood wrote:
| 
| > Either 2.4.9-ac16 has much improved VM performance over
| > previous 2.4 kernels (under moderate load, at least), or someone
| > sneaked in to my apartment last night and upgraded my machine
| > while I was asleep.  I'm leaning toward the latter explanation.
| 
| Now that the -ac VM was stable for a few weeks, I thought
| it might be time to sneak in some big performance changes,
| finally.
| 
| They seem to work ;)

  I have been playing with 2.4.9-ac16 and I note that on a small machine
(without the highmem issues) it really seems much slower initially.
After startx I pop up netscape for a test, and it takes almost 50%
longer than 2.4.8-pre3 I've been running since it was new. After that it
seems okay but not wildly better, my aim was to be able to use netscape
and cdrecord and {anything_else} at the same time.

  I'm measuring some figures now, and I have to dig out the location of
the preempt stuff and see if it's in already, or will slide in without
breaking. My bookmarks are on backup while I use the 2nd drive for
something else today :-(

-- 
bill davidsen <davidsen@tmr.com>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe

Re: 2.4.9-ac16 good perfomer?

[Rik van Riel]

On Fri, 28 Sep 2001, bill davidsen wrote:

>   I have been playing with 2.4.9-ac16 and I note that on a small machine
> (without the highmem issues) it really seems much slower initially.
> After startx I pop up netscape for a test, and it takes almost 50%
> longer than 2.4.8-pre3 I've been running since it was new. After that it
> seems okay but not wildly better, my aim was to be able to use netscape
> and cdrecord and {anything_else} at the same time.

Mmmm, interesting.  Could you send me a screen worth of
top output and maybe 10 or 20 lines or so of 'vmstat 1'
output, both taken while the machine is going through a
hard time ?

Lets try to resolve this issue while we're at it ;)

regards,

Rik
--
IA64: a worthy successor to the i860.

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

Re: 2.4.9-ac16 good perfomer?

[Pau Aliagas]

On Fri, 28 Sep 2001, Rik van Riel wrote:

> On Fri, 28 Sep 2001, bill davidsen wrote:
>
> > I have been playing with 2.4.9-ac16 and I note that on a small machine
> > (without the highmem issues) it really seems much slower initially.
> > After startx I pop up netscape for a test, and it takes almost 50%
> > longer than 2.4.8-pre3 I've been running since it was new. After that it
> > seems okay but not wildly better, my aim was to be able to use netscape
> > and cdrecord and {anything_else} at the same time.
>
> Mmmm, interesting.  Could you send me a screen worth of
> top output and maybe 10 or 20 lines or so of 'vmstat 1'
> output, both taken while the machine is going through a
> hard time ?
>
> Lets try to resolve this issue while we're at it ;)

I find it the best in 2.4 series :)
Opening a nautilus window in a directory with 1600 pictures taht usually
made the system unusable (a laptop) now doesn't affect much.

An important remaining glitch for me is what happens when the system is
idle for some time, for instance after the screensaver has been running
during lunch time; it takes a few seconds moving from desktop to desktop
til it "swaps in" applications again. Maybe we are throwing away pages too
aggressively?

Pau

Re: 2.4.9-ac16 good perfomer?

[Alan Cox]

> idle for some time, for instance after the screensaver has been running
> during lunch time; it takes a few seconds moving from desktop to desktop
> til it "swaps in" applications again. Maybe we are throwing away pages too
> aggressively?

-ac is throwing away dcache too aggressively currently, that needs
addressing in part by pruning the dcache and inode cache more smartly

Alan

Tools better than vmstat [was: 2.4.9-ac16 good perfomer?]

[Mike Fedyk]

On Fri, Sep 28, 2001 at 03:36:33PM -0300, Rik van Riel wrote:
> On Fri, 28 Sep 2001, bill davidsen wrote:
> > seems okay but not wildly better, my aim was to be able to use netscape
> > and cdrecord and {anything_else} at the same time.
> 
> Mmmm, interesting.  Could you send me a screen worth of
> top output and maybe 10 or 20 lines or so of 'vmstat 1'
> output, both taken while the machine is going through a
> hard time ?
> 
> Lets try to resolve this issue while we're at it ;)
> 
> Rik

Rik,

It seems to me that while you can get good information about the VM from
vmstat, it doesn't really give enough detail.

It doesn't give any info about the ages of pages, or anything detailed besides
sizes of memory caches, and amount of swaping.

I read not too long ago about someone mentioning a patch that lists the ages
of pages via a proc interface...

Does anything like this interest you?

Re: Tools better than vmstat [was: 2.4.9-ac16 good perfomer?]

[Mike Fedyk]

On Fri, Sep 28, 2001 at 09:04:53PM +0100, Russell King wrote:
> On Fri, Sep 28, 2001 at 12:34:55PM -0700, Mike Fedyk wrote:
> > I read not too long ago about someone mentioning a patch that lists the ages
> > of pages via a proc interface...
> 
> I have a patch that dumps out all sorts of information on sysrq-g and
> sysrq-h, including page ages as you describe above.  Rik has this patch,
> but you really do need a serial console and not a lot of RAM to use it
> (or a lot of patience).
> 

Hmm.

Ok, can someone tell me how many different ages there can be in the VM?  

I'm thinkin of a tool (vm-page-stat?) that will list the percentage of pages
at a specific (or if there are more than ~10 page ages possible, it could
use ranges...) age much like vmstat does now.

Is there any possibility of using Russell's patch for this user space tool?
Maybe Russel's patch could have a proc interface that vm-page-stat would
read to get a snapshot?

It would certainly be more helpful than vmstat alone...

Comments?

Re: Tools better than vmstat [was: 2.4.9-ac16 good perfomer?]

[Russell King]

On Fri, Sep 28, 2001 at 02:53:24PM -0700, Mike Fedyk wrote:
> Is there any possibility of using Russell's patch for this user space tool?

There is one property the kernel space method has over any user space
tool on a UP machine (and conceivably a SMP machine with more code) -
you get a complete atomic snapshot of the VM state.  Might be useful
and important, but might not be.

It would be pretty easy to change my kernel patch to produce what you're
requesting, from another sysrq key combination.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Tools better than vmstat [was: 2.4.9-ac16 good perfomer?]

[Mike Fedyk]

On Fri, Sep 28, 2001 at 11:00:34PM +0100, Russell King wrote:
> On Fri, Sep 28, 2001 at 02:53:24PM -0700, Mike Fedyk wrote:
> > Is there any possibility of using Russell's patch for this user space tool?
> 
> There is one property the kernel space method has over any user space
> tool on a UP machine (and conceivably a SMP machine with more code) -
> you get a complete atomic snapshot of the VM state.  Might be useful
> and important, but might not be.
>

Actually, I was suggesting a combined kernel and user space design.

/proc/vm-page-ages would give all of the gory numbers in an atomic way, and
vm-page-stat would distil that into the percentages much like vmstat
output...

> It would be pretty easy to change my kernel patch to produce what you're
> requesting, from another sysrq key combination.
> 

Is sysrq easier to code for, or initiate-on-proc-read?

I'm just sorry I don't know enough C to do this myself... :(

Re: Tools better than vmstat [was: 2.4.9-ac16 good perfomer?]

[Russell King]

On Fri, Sep 28, 2001 at 03:33:01PM -0700, Mike Fedyk wrote:
> Is sysrq easier to code for, or initiate-on-proc-read?

It's more to do with the framework that the debug code uses - you
effectively provide it with a function to do whatever analysis you
want on the pages, and it calls it for each and every page in each
zone.  After each zone, it calls it with NULL to allow you to
display any statistics you've gathered for the zone.

It repeats this across all nodes and all zones, so you get the full
picture.

There are currently two functions implemented - dump the raw data
for every single page in an easy to read format (but it is very
verbose, and takes a long time to dump out on large machines).
The second gives a summary of reserved, slab, ramdisk, free and
anonymous pages found in the zone.

I guess you'd need to do something like:

static unsigned int zone_age[MAX_AGE - MIN_AGE];

static void page_ages(struct page *page)
{
	int i;
	if (page) {
		zone_age[page->age - MIN_AGE]++;
		return;
	}

	for (i = MIN_AGE; i < MAX_AGE; i++) {
		printk("  Age %d: %u pages\n", i, zone_age[i]);
		zone_age[i] = 0;
	}
}

I'll dig out the patch tomorrow.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Tools better than vmstat [was: 2.4.9-ac16 good perfomer?]

[Mike Fedyk]

On Sat, Sep 29, 2001 at 12:00:00AM +0100, Russell King wrote:
> I'll dig out the patch tomorrow.
> 

You don't happen to have that patch available (in current form, of course)
somewhere for download do you? 

couldn't find a web site with your patches either, except for the ARM site,
and your personal page there...  Do you have a page with all of your misc
patches?

Also noticed there isn't a ftp.kernel.org/pub/linux/kernel/people/rmk...

Re: 2.4.9-ac16 good perfomer?

[Mike Fedyk]

On Fri, Sep 28, 2001 at 12:50:21AM -0300, Rik van Riel wrote:
> On Thu, 27 Sep 2001, Thomas Hood wrote:
> 
> > Either 2.4.9-ac16 has much improved VM performance over
> > previous 2.4 kernels (under moderate load, at least), or someone
> > sneaked in to my apartment last night and upgraded my machine
> > while I was asleep.  I'm leaning toward the latter explanation.
> 
> Now that the -ac VM was stable for a few weeks, I thought
> it might be time to sneak in some big performance changes,
> finally.
> 
> They seem to work ;)
> 

Is it normal to have Inact_target 1/4 of main memory (64MB of 256MB RAM)?
In previous versions, this value would fluctuate with the load of the system.

Is this expected?

Re: 2.4.9-ac16 good perfomer?

[Rik van Riel]

On Fri, 28 Sep 2001, Mike Fedyk wrote:

> Is it normal to have Inact_target 1/4 of main memory (64MB of 256MB RAM)?
> In previous versions, this value would fluctuate with the load of the system.
>
> Is this expected?

Yes, this is a 'compensation' for the fact that page aging changed
from exponential to linear.  The combination of linear page aging
with a large inactive_target results in a good combination of
frequency- and recency-based page eviction.

Doing just linear page aging with a small inactive target resulted
in worse throughput than exponential page aging for some workloads,
better for other workloads.  Linear page aging with a large inactive
target results in good througput and latency under all workloads I've
found up to now.  As usual, thanks go out to Matt Dillon for finding
this balancing point.

I guess it really is time to stop reinventing the wheel ;)

cheers,

Rik
-- 
IA64: a worthy successor to i860.

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

[Kinda-OT] Reinventing wheels [was: 2.4.9-ac16 good perfomer?]

[Mike Fedyk]

On Fri, Sep 28, 2001 at 10:20:37PM -0300, Rik van Riel wrote:
> As usual, thanks go out to Matt Dillon for finding
> this balancing point.
> 
> I guess it really is time to stop reinventing the wheel ;)
> 

I've read the archived thread between you and Matt, and he mentioned that
what he described was about three years old.

What did they do before that?

Re: 2.4.9-ac16 good perfomer?

[Daniel Phillips]

On September 29, 2001 03:20 am, Rik van Riel wrote:
> > Is it normal to have Inact_target 1/4 of main memory (64MB of 256MB RAM)?
> > In previous versions, this value would fluctuate with the load of the
> > system.
> >
> > Is this expected?
> 
> Yes, this is a 'compensation' for the fact that page aging changed
> from exponential to linear.  The combination of linear page aging
> with a large inactive_target results in a good combination of
> frequency- and recency-based page eviction.
> 
> Doing just linear page aging with a small inactive target resulted
> in worse throughput than exponential page aging for some workloads,
> better for other workloads.  Linear page aging with a large inactive
> target results in good througput and latency under all workloads I've
> found up to now.  As usual, thanks go out to Matt Dillon for finding
> this balancing point.

Nice.  With this under control, another feature of his memory manager you 
could look at is the variable deactivation threshold, which makes a whole lot 
more sense now that the aging is linear.  To implement it efficiently 
PAGE_AGE_DECL just needs to be a variable, since in effect the deactivation 
threshold already is exactly PAGE_AGE_DECL.

How to set this variable is a deep and interesting question.  Matt had his 
ideas on that as you know, and in fact it's a key feature of the BSD 
mm it, but it's far from clear that the BSD arrangement could be used 
directly in Linux.  There are a number of obvious difficulties: no reverse 
map, highmem, more caches to balance, and so on.  However, it's intuitively 
clear that the mm sweet spot can be made bigger by controlling the DECL 
variable, i.e., we can push the thrash point further out for a wider variety 
of loads.

Obligatory disclaimer: there is no burning issue here; this is a 
*developmental* idea.

--
Daniel

Load control (was: Re: 2.4.9-ac16 good perfomer?)

[Rik van Riel]

On Mon, 1 Oct 2001, Daniel Phillips wrote:

> Nice.  With this under control, another feature of his memory manager
> you could look at is the variable deactivation threshold, which makes
> a whole lot more sense now that the aging is linear.

Actually, when we get to the point where deactivating enough
pages is hard, we know the working set is large and we should
be _more careful_ in chosing what to page out...

When we go one step further, where the working set approaches
the size of physical memory, we should probably start doing
load control FreeBSD-style ... pick a process and deactivate
as many of its pages as possible. By introducing unfairness
like this we'll be sure that only one or two processes will
slow down on the next VM load spike, instead of all processes.

Once we reach permanent heavy overload, we should start doing
process scheduling, restricting the active processes to a
subset of all processes in such a way that the active processes
are able to make progress. After a while, give other processes
their chance to run.

regards,

Rik
-- 
IA64: a worthy successor to i860.

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Load control (was: Re: 2.4.9-ac16 good perfomer?)

[Daniel Phillips]

On October 1, 2001 03:57 pm, Rik van Riel wrote:
> On Mon, 1 Oct 2001, Daniel Phillips wrote:
> 
> > Nice.  With this under control, another feature of his memory manager
> > you could look at is the variable deactivation threshold, which makes
> > a whole lot more sense now that the aging is linear.
> 
> Actually, when we get to the point where deactivating enough
> pages is hard, we know the working set is large and we should
> be _more careful_ in chosing what to page out...

Naturally.  However, this is orthogonal.  Consider the case where you've hit 
the wall and the inactive list has suffered sudden depletion.  At this point 
you have to deactivate a large number of pages and you will have few or no 
intervening age-up events (because you hit the wall and nobody's moving).  
It's a useless waste of CPU and real time to cycle through the active list 5 
times to deactivate enough pages.  You should cycle through at most twice, 
once to age up any pages with Ref set and the second time to deactivate the 
required number of pages according to a threshold you estimated on the first 
pass.

This is just the first common example that came to mind where a variable 
deactivation threshold is obviously desirable, I'm sure there are others.

> When we go one step further, where the working set approaches
> the size of physical memory, we should probably start doing
> load control FreeBSD-style ... pick a process and deactivate
> as many of its pages as possible. By introducing unfairness
> like this we'll be sure that only one or two processes will
> slow down on the next VM load spike, instead of all processes.
> 
> Once we reach permanent heavy overload, we should start doing
> process scheduling, restricting the active processes to a
> subset of all processes in such a way that the active processes
> are able to make progress. After a while, give other processes
> their chance to run.

No question about the need for higher level process control, but the low 
level machinery could still be improved, don't you think?

--
Daniel