Re: percentage based CPU scheduling

From: Juhan Leemet (juhan_at_logicognosis.com)
Date: 08/06/04 

Date: Fri, 06 Aug 2004 14:36:23 -0200

On Thu, 05 Aug 2004 21:42:57 -0400, Jean-David Beyer wrote:
> Juhan Leemet wrote (in part):
>
>> BTW, sometimes SMP helps responsiveness of systems, by having more CPUs
>> available for runnable processes or interrupts. Tho under really heavy
>> loads all CPUs will get evenly loaded. That's as it should be!
>>
>> As an example, if I'm running setiathome twice on a dual SMP machine, I
>> do "feel it". The system is not quite as responsive as when that
>> constant background CPU load isn't there. I interpret that as the
>> higher probability of some task having to run until the end of its time
>> slice before that CPU is vailable for another process at the same
>> (normal) priority.
>>
> I have two hyperthreaded Xeon processors in this machine. Linux treats
> this as four processors, so I run four instances of setiathome. I run them
> at nice level 19, giving them the lowest probability of running.

I have not niced my setiathome processes down, not so much out of laziness
(well maybe) or ignorance, but mostly to see what the system "feels like"
under load. I think I will use nice in future. I've been meaning to...
where does time go?

> If a higher priority process becomes runnable, this is surely because some
> interrupt or another changed something to take it out of the wait state
> and stuck it in a ready queue. I do not believe the Linux kernel would
> allow a setiathome process to run until the end of its time slot before
> running a higher priority process.

In my case, since I have it "normal" priority, the probability is higher
that one of the setiathome processes gets dispatched.

I don't think Linux would run lower priority processes if there were
higher priority ones available. You are also right that "something
changed" to make a process runnable must be an external event: interrupt
of some kind. A runnable process can only make itself "not runnable".
Obviously, a non-running process cannot change its own state.

> But I do not dispute your feeling that the system becomes less responsive.
>
> E.g., I have an extremely IO intensive application (populating a
> database). If I run it with no instances of setiathome running, it takes
> about 35 minutes to run. If 4 instances of setiathome are running, it
> dakes between 45 and 50 minutes to run even though the dbms servers run at
> nice level 0 and PRI 15 to 25.
>
> It is my view that what is happening is not that the scheduler is failing
> to honor the priorities, but that when the IO limited process(es) start an
> IO, they lose the processor until the IO completes and during that time,
> setiathome dirtys up the L1, L2, and L3 caches so that the IO limited
> process, once it gets a processor, finds the cache hit ratio is zero;
> i.e., it is running out of the main RAM (533 MHz) instead of the Caches
> (running at the 3.06GHz processor speed), for about a 5.75x slowdown.

Very good point! Whenever a process starts I/O they are effectively giving
up their turn (to higher or equal priority processes). I hadn't thought
through the "dirtying caches" scenarios.

[going OT, sorta]
I have noticed, though that a Sun Ross HyperSparc Sparc20 machine with 4
CPUs and small caches was abysmal at setiathome. Another Sparc20 with dual
SM71s actually performed better. I had inferred that the problem was lack
of cache 4x256KB vs. 2x1MB. Your explanation helps make more sense out of
that empirical observation. I wasn't particularly upset, except to be a
bit disappointed in the quad Ross. It emphasized a point I made to an IT
manager years ago when they were upgrading CPUs on a server (M$ I think)
and I was astounded that the manager didn't know how much cache (before or
after) and yet they were planning to upgrade some marginal amount (less
than 2x or 3x, which I've used as an "engineering rule of thumb").

>>> Neither nice nor the total cpu time are usable for this. I found two
>>> schedulers in the internet:
>
> What two schedulers?

See the OP post. I haven't experimented with them. Just glanced. 

-- 
Juhan Leemet
Logicognosis, Inc.

Relevant Pages

  • Re: [PATCH] sched: smpnice work around for active_load_balance()
    ... It is undesirable for HT/MC packages to have more than one of their CPUs ... I can show lots of examples where load balancing fails to do the right thing without the smpnice patches so it becomes a matter of which are more important. ... of different priority tasks... ...
    (Linux-Kernel)
  • RE: [PATCH] 2.6.0 batch scheduling, HT aware
    ... Regarding H/W-based priority, I'm not sure it's very useful especially ... >>I've done a resync and update of my batch scheduling that is also ... and for HT cpus only allows idle time when both ... >>the mainline HT scheduler if it ever gets included. ...
    (Linux-Kernel)
  • Re: RT task scheduling
    ... Starting 4 offense threads at priority 15 ... Starting referee thread ... The ball position is irrelevant ... all available CPUs. ...
    (Linux-Kernel)
  • Re: [PATCH] 2.6.0 batch scheduling, HT aware
    ... >Why do I need hyper-thread aware batch scheduling? ... >physical cpu's capacity no matter how high priority tasks you are running. ... Batch scheduling for normal cpus allows only idle time to be used ...
    (Linux-Kernel)