Re: percentage based CPU scheduling

From: Jean-David Beyer (jdbeyer_at_exit109.com)
Date: 08/06/04 

Date: Thu, 05 Aug 2004 21:42:57 -0400

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.

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.

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.
>
>> Neither nice nor the total cpu time are usable for this. I found two
>> schedulers in the internet:
>

What two schedulers? 

-- 
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 21:25:00 up 1 day, 13:00, 3 users, load average: 0.05, 0.12, 0.29

Relevant Pages

  • Re: [PATCH] sched: staircase deadline misc fixes
    ... has either missed the tick ofter enough, or accumulated enough cross cpu ... fairness based design. ... * ie, where 0 means a slot for that priority, priority running from left to ... Under niced loads it is 99% in favour of SD. ...
    (Linux-Kernel)
  • Re: 32bit vs 64bit
    ... CPU intensive tasks. ... 32 bit was the longer registers and wider path to memory. ... will just not see any measurable difference, due to a lack of large ... Obviously there are loads which do show a larger difference, ...
    (Fedora)
  • Re: Uses for memory barriers
    ... only in the following two cases: for MMIO and for sharing memory ... (Ceci n'est pas un CPU!) ... might disagree on the order in which given loads and stores occurred. ...
    (Linux-Kernel)
  • Re: Uses for memory barriers
    ... the action of memory barriers. ... (Ceci n'est pas un CPU!) ... might disagree on the order in which given loads and stores occurred. ...
    (Linux-Kernel)
  • Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark
    ... >> for some of the loads you really are going to be independant of the speed ... >> of the hardware however ... >> of the cpu doesn't seem right. ... however if you defined these loads in terms of the amount of work (number ...
    (Linux-Kernel)