Re: some more nifty benchmarks

[Ed Sweetman]

On Fri, 2002-04-05 at 15:37, Dieter Nützel wrote:
> On Freitag, 5. April 2002 :22, Ed Sweetman wrote:
> > On Thu, 2002-04-04 at 22:49, Dieter Nützel wrote:
> > > On Tuesday, March 2002-04-02 17:15:40, Ed Sweetman wrote:
> 
> [-]
> 
> > > Yep, FOUND it.
> > > Ingo`s latest sched-O1-2.4.18-pre8-K3 is the culprit!!!
> > > Even with -ac (2.4.19-pre2-ac2) and together with -aa (latest here is
> > > 2.4.18-pre8-K3-VM-24-preempt-lock).
> > >
> > > Below are the number for 2.4.18+sched-O1-2.4.18-pre8-K3.
> > > Have a look into the attachment, too.
> > >
> > > Hopefully you or Ingo will find something out.
> >
> > I seem to have lost your earlier emails.  Did you get a max latency of
> > around <2 before this 0(1) scheduler patch?
> 
> In short:
> 
> YES with 2.4 and with preemption+lock-break
> I repeated it for 2.4.19-pre5+vm33. See results below.
> 
> It is NOT in any case an -aa VM or preemption+lock-break bug.
> Ingo's latest sched-O1-2.4.18-pre8-K3.patch for 2.4 is the culprit. So all 
> latest -ac kernels are broken in this sense, too.
> 
> > 2.2 with low latency patch gets that.  2.4 with low latency patch is many
> > many times worse.  The high latency areas of the kernel are already known.
> 
> I know :-)
> Bad we badly need a newer lock-break for 2.4 from Robert (sorry Andrew :-).
> I will do some "stats data collection" with my next boot.
> 
> >  It's just a matter of deciding how to deal with them that's the problem.
> > It seems that it might be a general consensus that it can't be dealt with
> > in 2.4 mainstream.
> 
> No I think it is not.
> If we can eliminate the remaining bugs from O(1) and use preemption everything 
> should be smooth.
> 
> > As you've implied before though,  the scheduler is much more important
> > than latency is to the average user.
> 
> The O(1)-scheduler is great but broken (latency wise) in the current 2.4 
> version. Have anyone of you some older versions from Ingo around?
> 
> > As most people would know from
> > 2.2, audio would skip unless it was running -20 nice and the highest
> > priority etc.  With 2.4's scheduler and preempt, well you dont have to
> > worry about skips and you can leave the player at a normal nice and
> > priority value.
> 
> That's not true with the O(1)-scheduler.
> In most of my tests (Ingo got my results) you have to renice the audio daemon 
> to something like -16 (first "real time" class) and X to -10 (for good 
> interactivity) during "heavy" background stuff (40 gcc and 40 g++ processes 
> reniced +19 for example). This load resulting in ~350 processes, 80~85 
> running in parallel and sound playing on my "old" 1 GHz Athlon II with 640 
> MB...;-)

You realize that if you run enough processes your timeslice for all
proccesses sharing that priority is decreased. Decoding and audio
playing needs at least an N length timeslice and from the sound of it,
you're just running so many running processes that the length of that
priority's timeslice is below N.   There is nothing a schedular can do
about that, it's being fair.  Of course if you want something to run
with 350 other running processes you'll have to make it a higher
priority, if you let it be fair then it's timeslice is just too small
for it with that many divisions of your cpu.  You cant expect the kernel
to autodetect the functionality of the programs it's running and
auto-tune for usable performance, that's the user's job. 

What people complain about is a couple processes having the same effect
as running 350 procesess.  I dont see that at all with preempt anymore. 
There is no need to renice anything in a preempt kernel unless you know
you'll be running so many processes that your timeslice is just going to
be too small for applications that care.  This used to be the case in
2.2 back when i used it and before the preempt and new schedular patches
for 2.4.x. 

Running a couple apps and having it affect audio playing is something
you shouldn't expect to occur.  But running hundreds of programs and
having it affect audio playing is perfectly acceptable if they're all at
the same priority.  Would you say that it's the kernel's fault for
skipping on your 486 66Mhz cpu? no, you just dont have the processing
time/s to do what needs to be done, that's all that's happening with
your 350 processes at once on your 1Ghz cpu. it's preemption and
scheduling the way it's supposed to be,  before you'd only need one
process that hogged the cpu in kernel to bring your audio to a halt.    

An alternative fix would be to run your forkbombs and/or massively
threaded apps at +10 or so since it's a rare case that running so many
running processes is "normal use" 

 
> But that's not so good for the "normal" user. We need some "auto renicing".
> 
> BTW My former 2.4.17/2.4.18-pre numbers were much better for throughput and 
> somewhat for latency.
> 
> I used Andrea's -aa VM and Robert's preemption and lock-break on ReiserFS all 
> the time. But together with bootmem-2.4.17-pre6 and waitq-2.4.17-mainline-1.
> Anyone know where I can get newer versions of them?