Benchmarks for performance patches (-ck) for 2.4.19

Benchmarks for performance patches (-ck) for 2.4.19

[Con Kolivas]

My merged patchset (http://kernel.kolivas.net) was designed to improve system
responsiveness. I have yet to find a good benchmark that measures such a thing.
However, in response to criticism about not providing benchmarks I have made
available some standard benchmarks at the excellent resources of the open source
development laboratory scalable test platform. They are available here:

http://www.osdl.org/stp

my patchsets are the following:
-ck5 patch is patch #781
-ck5-rmap is #782
-ck5-ll is #783

I have conducted some basic tests on #781 and the numbers show it is at least
equivalent to stock 2.4.19 (#747), although as I said none of these benchmarks
are designed to test desktop system responsiveness.

Please feel free to conduct any tests you like on these patches. I would be
interested to hear if anyone can suggest the most suitable benchmark. Please cc
me to ensure I receive any comments.

Con Kolivas

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Ed Sweetman]

Wouldn't the majority (to an undeniable extent) of the "responsiveness" 
of desktop usage be on X's code? if we are talking about that.  The 
problem with finding a benchmark is that first you have to have a 
definition of what you're benchmarking.  The "system responsiveness" 
term is far too vague. When there's a definition to the term there can 
be a benchmark made to measure it. I mean, besides making the kernel 
with as low latency as possible, what is bad about the responsiveness in 
the kernel?   If there's any lag in responsiveness that i see it's 
always something X related, particularly Xfree86.

You can't really benchmark something where everyone's issues are "things 
go slow when i use "some" benchmark and try using my computer at the 
same time" or "it feels better or worse."   I'd be quite interested in 
making a benchmark and/or using it to help responsiveness in linux, who 
wouldn't want that?  But I just think we have a fairly good kernel and 
the bottleneck is not it in the case of the majority of users and what 
they report as "system responsiveness."  As computers get faster and 
faster we expect to see that reflected in the software we use, perhaps 
it's just making some design issues with X more apparent ...perhaps not. 
  Just some food for thought.




Con Kolivas wrote:
> My merged patchset (http://kernel.kolivas.net) was designed to improve system
> responsiveness. I have yet to find a good benchmark that measures such a thing.
> However, in response to criticism about not providing benchmarks I have made
> available some standard benchmarks at the excellent resources of the open source
> development laboratory scalable test platform. They are available here:
> 
> http://www.osdl.org/stp
> 
> my patchsets are the following:
> -ck5 patch is patch #781
> -ck5-rmap is #782
> -ck5-ll is #783
> 
> I have conducted some basic tests on #781 and the numbers show it is at least
> equivalent to stock 2.4.19 (#747), although as I said none of these benchmarks
> are designed to test desktop system responsiveness.
> 
> Please feel free to conduct any tests you like on these patches. I would be
> interested to hear if anyone can suggest the most suitable benchmark. Please cc
> me to ensure I receive any comments.
> 
> Con Kolivas
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Rik van Riel]

On Sun, 1 Sep 2002, Ed Sweetman wrote:

> Wouldn't the majority (to an undeniable extent) of the "responsiveness"
> of desktop usage be on X's code? if we are talking about that.  The
> problem with finding a benchmark is that first you have to have a
> definition of what you're benchmarking.  The "system responsiveness"
> term is far too vague. When there's a definition to the term there can
> be a benchmark made to measure it.

Agreed. Things like system responsiveness are fairly complex
though and in many cases the average numbers measured by
benchmarks don't mean anything to users.

I wish we had a way to measure this stuff, but I'll happily
philosophise with you guys until we come up with a useful
definition of something we could measure...

> I mean, besides making the kernel with as low latency as possible, what
> is bad about the responsiveness in the kernel?  If there's any lag in
> responsiveness that i see it's always something X related, particularly
> Xfree86.

"low latency" != responsiveness

Any latency which is below the point the user can notice
is effectively zero, so whether the 10000 wakeups/minute
that the user doesn't notice are 2ms or 5ms don't really
matter.

What does matter are the wakeups that make the user's
mp3 skip, even if these don't influence the statistics
at all because there's only 1 every few minutes, or none,
if the VM is balanced right ;)

Another responsiveness thing is how fast you can swap in
Mozilla when the user comes in in the morning. More of a
throughput than a latency thing in this case ... but you
still have to make sure the mp3 doesn't skip while mozilla
is being loaded.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

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

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Ed Sweetman]

Rik van Riel wrote:
> On Sun, 1 Sep 2002, Ed Sweetman wrote:
> 
> 
>>Wouldn't the majority (to an undeniable extent) of the "responsiveness"
>>of desktop usage be on X's code? if we are talking about that.  The
>>problem with finding a benchmark is that first you have to have a
>>definition of what you're benchmarking.  The "system responsiveness"
>>term is far too vague. When there's a definition to the term there can
>>be a benchmark made to measure it.
> 
> 
> Agreed. Things like system responsiveness are fairly complex
> though and in many cases the average numbers measured by
> benchmarks don't mean anything to users.
> 
> I wish we had a way to measure this stuff, but I'll happily
> philosophise with you guys until we come up with a useful
> definition of something we could measure...
> 
> 
>>I mean, besides making the kernel with as low latency as possible, what
>>is bad about the responsiveness in the kernel?  If there's any lag in
>>responsiveness that i see it's always something X related, particularly
>>Xfree86.
> 
> 
> "low latency" != responsiveness
> 
> Any latency which is below the point the user can notice
> is effectively zero, so whether the 10000 wakeups/minute
> that the user doesn't notice are 2ms or 5ms don't really
> matter.

true.  But the latency that's N low multiplied by many processes can 
equal latencies that are in the range users can notice in a single app 
that maybe getting bullied by the others.  Lowering latencies cant be a 
bad thing unless they create unelegent code or introduce bugs.  That's 
all i meant by mentioning latency.

> What does matter are the wakeups that make the user's
> mp3 skip, even if these don't influence the statistics
> at all because there's only 1 every few minutes, or none,
> if the VM is balanced right ;)
> 
> Another responsiveness thing is how fast you can swap in
> Mozilla when the user comes in in the morning. More of a
> throughput than a latency thing in this case ... but you
> still have to make sure the mp3 doesn't skip while mozilla
> is being loaded.

Maybe i'm weird then because I've never had that happen.  The only time 
i've had my mp3s skip is when i purposely did things that would do that 
(saturate via bonnie or dbench).  I can see this occuring during 
swapping when dma is not used, but this just adds to the fact that it's 
no easy matter to define the problem.

> regards,
> 
> Rik

I dont experience audio cutouts with anything i do, even the really 
abusive things to the computer.  I've only had it cut out when using 
bonnie or dbench and that's something you should expect. So what i see 
as responsiveness is switching windows on the same desktop and switching 
between virtual desktops.  I see responsiveness as the time between i do 
something and the time it takes to redraw it. Using a G450, I expect a 
certain level of hardware performance and half a second or so to redraw 
a screen is not what i call responsive for a Tbird system. This is of 
course all X related because i dont see much or any problem with the 
console and with the kernel. At least nothing compared to X latencies.

the common user wants to see desktop performance equal to mac osX and 
windows and they come to linux which uses X and dont see that.  The 
problem is Xfree86 is a crossplatform network oriented windowing system 
and you get the same argument with it that people have with gcc.  The 
purpose of xfree86 and gcc is kind of the same and not the same as these 
other propriatary systems / compilers such as OSX or icc.  It's tough 
luck for us all but this is something that the xpert mailing list could 
better handle since what we're looking for is a tool that measures the 
performance of X under real workloads and where problem areas are.

Both the kernel and the programs used are involved when talking "system 
responsiveness" but in this case i think the kernel has been fine tuned 
much more strictly and thoroughly than xfree86 has.  I'd like to know if 
that's due to lack of man/woman power or if they're being restricted by 
compliance to aspects of X that maybe need to change as use has changed.

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Ingo Oeser]

Hi Ed,
Hi Rik,
Hi lkml,

On Mon, Sep 02, 2002 at 12:00:39AM -0400, Ed Sweetman wrote:
> I dont experience audio cutouts with anything i do, even the really 
> abusive things to the computer.  I've only had it cut out when using 
> bonnie or dbench and that's something you should expect. So what i see 
> as responsiveness is switching windows on the same desktop and switching 
> between virtual desktops.  I see responsiveness as the time between i do 
> something and the time it takes to redraw it. Using a G450, I expect a 
> certain level of hardware performance and half a second or so to redraw 
> a screen is not what i call responsive for a Tbird system. This is of 
> course all X related because i dont see much or any problem with the 
> console and with the kernel. At least nothing compared to X latencies.
 
This is not only X. The problem is the software layering bloat.
Thats a design mistake we copied from W*ndows in our Linux
applications.

Take your favorite - and I mean your favorite, not the easiest -
application, find the handler for the problem event, try to do a
really complete call graph trough all software layers involved
(say from read(inputdevice_fd) to get the event up to
write(outputdevice_fd) to write to the framebuffer) and count
cycles. Don't forget the cache misses due to following pointers,
which lead to random, non-local memory access patterns 
(read: a VM and cache nightmare).

Once you really finish this boring task completely you know our
real performance problem.

Felix von Leitner did a nice presentation on our 
Chemnitzer Linux Tag (but in German) and many experienced
programmers and software enginieers were really stunned.

So the problem is not really the kernel or the X layer. The
NUMBER of abstraction layers is the issue to attack.

People tend to import big bloated libraries or even completely
overkill operating systems just because it has ONE SIMPLE
property the actually need[1]. This must change.


Regards

Ingo Oeser

[1] Buying/Reselling Windows NT licenses + some Windows FTP
   server license just because we need FTP. Buying WinCE
   licenses, just because the embedded device must be able to be
   accessible via TCP/IP. More examples available per private
   mail. Stupidity has no limit here.
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Rik van Riel]

On Mon, 2 Sep 2002, Ingo Oeser wrote:

> This is not only X. The problem is the software layering bloat.
> Thats a design mistake we copied from W*ndows in our Linux
> applications.

Agreed, it is not just in one layer of the system.

However, changing the kernel _has_ resulted in a large
improvement in interactivity and does allow me to run
bonnie++ or even a 'bk clone' while playing mp3s and
without losing interactivity or having the mp3s skip...

On a machine with 192 MB RAM.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

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

Re: Benchmarks for performance patches (-ck) for 2.4.19

[jw schultz]

On Mon, Sep 02, 2002 at 09:39:10AM +0200, Ingo Oeser wrote:
> Hi Ed,
> Hi Rik,
> Hi lkml,
> 
> On Mon, Sep 02, 2002 at 12:00:39AM -0400, Ed Sweetman wrote:
> > I dont experience audio cutouts with anything i do, even the really 
> > abusive things to the computer.  I've only had it cut out when using 
> > bonnie or dbench and that's something you should expect. So what i see 
> > as responsiveness is switching windows on the same desktop and switching 
> > between virtual desktops.  I see responsiveness as the time between i do 
> > something and the time it takes to redraw it. Using a G450, I expect a 
> > certain level of hardware performance and half a second or so to redraw 
> > a screen is not what i call responsive for a Tbird system. This is of 
> > course all X related because i dont see much or any problem with the 
> > console and with the kernel. At least nothing compared to X latencies.
>  
> This is not only X. The problem is the software layering bloat.
> Thats a design mistake we copied from W*ndows in our Linux
> applications.
> 
> Take your favorite - and I mean your favorite, not the easiest -
> application, find the handler for the problem event, try to do a
> really complete call graph trough all software layers involved
> (say from read(inputdevice_fd) to get the event up to
> write(outputdevice_fd) to write to the framebuffer) and count
> cycles. Don't forget the cache misses due to following pointers,
> which lead to random, non-local memory access patterns 
> (read: a VM and cache nightmare).
> 
> Once you really finish this boring task completely you know our
> real performance problem.
> 
> Felix von Leitner did a nice presentation on our 
> Chemnitzer Linux Tag (but in German) and many experienced
> programmers and software enginieers were really stunned.
> 
> So the problem is not really the kernel or the X layer. The
> NUMBER of abstraction layers is the issue to attack.
> 
> People tend to import big bloated libraries or even completely
> overkill operating systems just because it has ONE SIMPLE
> property the actually need[1]. This must change.

I dont' believe it is really X11.  The real killer of
perceived performance seems to be the pager.  Great strides
have been made here but i find that file I/O seems to be
replacing often used pages so that when i change desktops or
touch something that i haven't used for a while it stalls
while my disk drive sounds like a nest of hornets.  I
shouldn't see THAT much difference in behavior between a 10
minute and a 2 minute interval when i have plenty of memory
to hold my working set.  Backups and updatedb are guaranteed
to effect this.

It is of course most noticable with the large multi-layered
GUI apps because a single event faults far too many pages as
it works its way sparsely through the multiple libraries and
their respecitive data.  Readahead would help more if there
was better locality.

Unfortunately there isn't much we are going to be able to do
about this at the application level.  Perhaps the libraries
could be optimized by reducing the layering but that is a
matter for other lists.

The one thing the kernel can do is to not reclaim my often
used pages when the pagecache is full of stale data that is
unlikely to be reused.  Yes, i know this is HARD to do but
it needs to be better.  I appreciate all those with
headaches from trying to fix this.

There was a patch that went by here recently that looked
promising to me.  If i recall correctly it put newly read
pages onto a special list so that if they didn't get read
again before reaching the bottom the were reused.  Otherwise
the wound up on the LRU.  

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Paul]

Rik van Riel <riel@conectiva.com.br>, on Sun Sep 01, 2002 [11:32:42 PM] said:
> On Sun, 1 Sep 2002, Ed Sweetman wrote:
> > I mean, besides making the kernel with as low latency as possible, what
> > is bad about the responsiveness in the kernel?  If there's any lag in
> > responsiveness that i see it's always something X related, particularly
> > Xfree86.
> 
> "low latency" != responsiveness
> 
> Any latency which is below the point the user can notice
> is effectively zero, so whether the 10000 wakeups/minute
> that the user doesn't notice are 2ms or 5ms don't really
> matter.
> 
> What does matter are the wakeups that make the user's
> mp3 skip, even if these don't influence the statistics
> at all because there's only 1 every few minutes, or none,
> if the VM is balanced right ;)
> 
> Another responsiveness thing is how fast you can swap in
> Mozilla when the user comes in in the morning. More of a
> throughput than a latency thing in this case ... but you
> still have to make sure the mp3 doesn't skip while mozilla
> is being loaded.
> 
> regards,
> 
> Rik

	Hi;

	I just thought I would toss this in: For some classes
of users, latency is extremely critical. For example, people
making music live, doing realtime audio effects processing, or
recording audio. These people would probably like it below 2ms.
	mp3 playing latency requirements are very
loose-- the buffer takes up the slack, unless the latency is
insane.
	The good news is that for me, using the ck4 patchset,
my smp system is stable, and has a max latency of 3.5ms under
latencytest (during a make -j4 kernel compile no less) _and_
outperformed (slightly) virgin 2.4.19 on generic benchmarks.
(like building a kernel, bonnie,...)	
	Latency may not be the holy grail, but it remains
a valid requirement for a class of user. It may not merit
degredation for the common case, but perhaps it need not?

Paul
set@pobox.com

ps. ck4 uses the aa vm, but if there was a version with rmap,
I would test it.

Re: Benchmarks for performance patches (-ck) for 2.4.19

[J Sloan]

The ck5 kernel comes in more than one flavor

rmap, aa and low latency are offered -

I'm running 2.4.19-ck5-ll and I'm happy to report
that it also plays well with freeswan ipsec - I'm
running freeswan 1.98b and it's all good - not to
mention the nice smooth feel in multimedia and
3D fps shooters ;-)

Thanks to conman for the tedious patching work!

Joe

Paul wrote:

>ps. ck4 uses the aa vm, but if there was a version with rmap,
>I would test it
>

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Andrew Morton]

Paul wrote:
> 
> ...
>         I just thought I would toss this in: For some classes
> of users, latency is extremely critical.

There are several types of latency: interrupt, scheduling, IO, probably
more.

The ones we're most interested in are scheduling latency and IO
latency.

These are two utterly, completely, wildly different things!  They differ
by two or three orders of magnitude and their underlying causes and
effects are quite different.

Let's please be careful in making the distinction between the two.

scheduling latency is pretty specialised.  You have to push the
system pretty hard to experience a scheduling stall which is longer
than a monitor refresh interval.  I don't believe that scheduling latency
is perceptible in desktop use.  Audio, yes.  Games, maybe.

IO latency is a much larger problem in Linux.  Once you start pushing the
system it pops up all over the place.  One simple test I use to quantify
this is:

- boot with mem=512m
- perform a continuous appending write to an ext2 file on a scratch
  disk.
- Now see how long it takes to build a kernel on a different disk.

This is not a completely silly scenario, and we have problems.  I have
one (dopey, hate it) patch which reduces that kernel build time by 30%.

The problem is that `gcc' is being forced to write back data to that
scratch disk within the page allocator.  It will take some algorithmic
rework in the VM to fix this properly.

Another prominent source of latency is at the disk request layer, where
heavy writers starve readers.  There's a hack^Wfix in Alan's kernels
for this, but nobody has discussed in in a while and I'm not sure how
useful it is being.

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Dieter Nützel]

Hello Con,

I have your ck5_2.4.19.patch with some additional stuff running fine on my 
dual Athlon MP 1900+, MSI K7D Master-L, 1 GB DDR-SDRAM 266 CL.

ck5 + some 2.4.19-jam0 stuff (Andrea, Ingo, others)

000_e100-2.1.6 (-AA)
000_e1000-4.3.2 (-AA)
00_387-fix-1
10-module-size-checks
12-memparam
24-config-nr_cpus
30-smptimers-A0
30_irq-balance-12
31-nr_requests
70-i2c-2.6.4
71-sensors-2.6.4

2.4.19.pending ReiserFS stuff
linux-2.4.19-ntfs-2.1.0a.patch
page_color-2.4.19-pre10-1 (Page coloring)

I'm from Robert Love's "side" and have his stuff running on top of 2.4 for 
nearly one year, now.

The first bench I try is latencytest-0.42-png all the time.
http://www.gardena.net/benno/linux/audio/

Then I try dbench (Yes, I know Rik ;-) to see the GREAT speed of Andrea 
Arcangeli's -AA VM which improve noticeably with the Preemption patch.
O(1) gave some additional speed, too.

What about Robert's nice Preemption Latency Measurement Tool?
http://www.tech9.net/rml/linux

I tried it many times to gave Robert some feedback.

Regards and good work!

-Dieter


-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel at hamburg.de (replace at with @)

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Rik van Riel]

On Mon, 2 Sep 2002, Dieter [iso-8859-15] Nützel wrote:

> Then I try dbench (Yes, I know Rik ;-)

It's fine that you run dbench, but if you can't explain the
numbers they're not worth the disk space it takes to write
them down ;)

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

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

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Con Kolivas]

Quoting Dieter Nützel <Dieter.Nuetzel@hamburg.de>:

> I have your ck5_2.4.19.patch with some additional stuff running fine on my 
> dual Athlon MP 1900+, MSI K7D Master-L, 1 GB DDR-SDRAM 266 CL.

Great to hear. I'd be impressed if you noticed *any* change in responsiveness
with anything on that machine.

> ck5 + some 2.4.19-jam0 stuff (Andrea, Ingo, others)
> 
> 000_e100-2.1.6 (-AA)
> 000_e1000-4.3.2 (-AA)
> 00_387-fix-1
> 10-module-size-checks
> 12-memparam
> 24-config-nr_cpus
> 30-smptimers-A0
> 30_irq-balance-12
> 31-nr_requests
> 70-i2c-2.6.4
> 71-sensors-2.6.4
> 
> 2.4.19.pending ReiserFS stuff
> linux-2.4.19-ntfs-2.1.0a.patch
> page_color-2.4.19-pre10-1 (Page coloring)
> 
> I'm from Robert Love's "side" and have his stuff running on top of 2.4 for 
> nearly one year, now.
> 
> The first bench I try is latencytest-0.42-png all the time.
> http://www.gardena.net/benno/linux/audio/

That's a very nice test, but as you've seen, pure latency is not everything. If
you want just that you should try my ck5-ll patch which gives the lowest
latencies (check my website for the benchmarks on -ck4 which used this -ll branch).

> Then I try dbench (Yes, I know Rik ;-) to see the GREAT speed of Andrea 
> Arcangeli's -AA VM which improve noticeably with the Preemption patch.
> O(1) gave some additional speed, too.

Yes, dbench is included in the many tests available at the the Open Source
Development Lab (osdl.org) along with many others.

> What about Robert's nice Preemption Latency Measurement Tool?
> http://www.tech9.net/rml/linux

Once again a pure latency measure, no?

> I tried it many times to gave Robert some feedback.
> 
> Regards and good work!

Thanks, glad you enjoy it, but it's really the combined efforts of the real
developers as you know.

Thanks for your feedback
Con

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Randy.Dunlap]

On Mon, 2 Sep 2002, Con Kolivas wrote:

| Quoting Dieter Nützel <Dieter.Nuetzel@hamburg.de>:

snippage...

| > Then I try dbench (Yes, I know Rik ;-) to see the GREAT speed of Andrea
| > Arcangeli's -AA VM which improve noticeably with the Preemption patch.
| > O(1) gave some additional speed, too.
|
| Yes, dbench is included in the many tests available at the the Open Source
| Development Lab (osdl.org) along with many others.

That makes it good, right?  8;)

Actually we are going thru our workloads and trying to
identify what they measure, what they are good for, etc.,
so if you have feedback in this area, please give it to us,
for the workloads that we run on each new kernel (2.5.x
or 2.4.x-marcelo).

-- 
~Randy

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Con Kolivas]

Quoting J Sloan <joe@tmsusa.com>:

> The ck5 kernel comes in more than one flavor
> 
> rmap, aa and low latency are offered -
> 
> I'm running 2.4.19-ck5-ll and I'm happy to report
> that it also plays well with freeswan ipsec - I'm
> running freeswan 1.98b and it's all good - not to
> mention the nice smooth feel in multimedia and
> 3D fps shooters ;-)
> 
> Thanks to conman for the tedious patching work!
> 
> Joe
> 
> Paul wrote:
> 
> >ps. ck4 uses the aa vm, but if there was a version with rmap,
> >I would test it


Actually Paul was correct; the low latency branch was just -aa but in my never
ending descent into madness I have decided to add another branch as requested,
ck5-rl which has lowest latency with -rmap instead of -aa

Get it at the usual place:
http://kernel.kolivas.net

Con.

P.S. You're welcome Joe.

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Paul]

Con Kolivas <conman@kolivas.net>, on Mon Sep 02, 2002 [07:12:07 PM] said:
> Actually Paul was correct; the low latency branch was just -aa but in my never
> ending descent into madness I have decided to add another branch as requested,
> ck5-rl which has lowest latency with -rmap instead of -aa
> 
> Get it at the usual place:
> http://kernel.kolivas.net
> 
> Con.
> 
> P.S. You're welcome Joe.
> 

	Hi;

	pII 400x2 512M SMP
	Running ck5-rl now. Benno's latencytest shows that
schedualing latency is perhaps better than the patchset with
the aa vm. My first run yeilded a max 2.7ms latency-- oddly
during the /proc loading test, instead of disk write which
seems most problematic here. Every other stress test yeilded
1.6ms max latency. A second run managed to pull off 1.5ms
max latency for most, and a 1.7ms latency for disk write.
	Under extreme stress (make -j4 bzImage) while running
the tests, both aa and rmap performed about the same. (3.5ms
max lat.)
	Under more general benchmarks, like lmbench, bonnie,
hdparm, and a kernel build, rmap came out the same or just
a little worse than aa. (in the context of these patchsets)
	Andrew Morton's low latency patch seems to be the
most signifigant aspect in acheiving these low schedualing
latencies-- turning it off in /proc/sys/kernel/lowlatency
results in readings, which are better than 2.4.19 virgin,
but still unworkable for applications which require consistant
low schedualing latency.
	My focus on these tests is related to my (diletante)
interest in audio processing and recording. I think the
interactive 'feel' of the system is improved, but I didnt
really have trouble with vanilla-- on this system, IO is
my real limiter. I am curious how these patchsets affect games,
but I dont have much gaming experience...
	If anyone wants me to run any benchmarks, just
ask. Thanks, Con. (and of course, the authors of the patchs)

Paul
set@pobox.com

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Martin Knoblauch]

>> I mean, besides making the kernel with as low latency as possible, 
what 
>> is bad about the responsiveness in the kernel? If there's any lag in 
>> responsiveness that i see it's always something X related, 
particularly 
>> Xfree86. 
>
>
>"low latency" != responsiveness 
>
>
>Any latency which is below the point the user can notice 
>is effectively zero, so whether the 10000 wakeups/minute 
>that the user doesn't notice are 2ms or 5ms don't really 
>matter. 

 absolugtely correct. My main grief wrt. responsiveness of desktop 
systems is when the VM decides to grow the cache at the cost of pushing 
parts of KDE into swap. As a result, "activating" windows that I 
haven't touched for some time takes noticeable delays, which ruins the 
interactiveness.

 My best setup for this is to have lots of memory and disable swap (and 
live with the consequences- eg. triggering the OOM killer).

 Admittedly, things seem to be much better now than six month ago.

Martin
-- 
Martin Knoblauch
Senior System Architect
MSC.software GmbH
Am Moosfeld 13
D-81829 Muenchen, Germany

e-mail: martin.knoblauch@mscsoftware.com
http://www.mscsoftware.com
Phone/Fax: +49-89-431987-189 / -7189
Mobile: +49-174-3069245

Re: Benchmarks for performance patches (-ck) for 2.4.19

[Wade]

Although you reported that ck5 fixed the "Deactivating swap.." freeze, I 
hit it last night, on ck5.