Two things I'd like to note here:

1. If you're really nice-ing your make process(es) to -20 (minus 20)
    you're actually doing the exact opposite of what you wanted to do.

    A negative nice value means more CPU time for the process, not
    less.

    Have another look a the nice(1) man page or maybe the man page
    of your shell (as you seem to be using a shell-builtin nice
    command).

2. If your machine is not a real multi-processor machine (with
    more than one physical CPU) but one of those "hyper-threading"-
    enabled P4s, then the scheduler may not quite get things right.

    Though I can't explain this any further I know that the scheduler
    would have to be specially adapted to make optimal use of such
    a CPU, and as far as I know this hasn't happened (yet).

    With the scheduler in it's current state, you might get any of
    better/same/worse results with a MP kernel (compared to an UP
    kernel), depending on what you do.

    But then again, if this doesn't apply to you (and the above
    doesn't help), something different is wrong and someone else will
    have to chime in.


Regards,
Tom


Wolfgang S. Rupprecht wrote:
> For years I've been happy with nice-ing the hell out of compiles
> (eg. a "nice -20" for anything that wasn't interactive) and all the
> interactive tasks seemed snappy enough.  There was never a problem
> with doing a full build and playing music at the same time.  Music got
> first dibs at the cpu and make/cc/as/ld and cohorts got whatever was
> left over.  That doesn't seem to be the case with the MPACI kernel.
> mpg123 isn't getting enough cycles to fill the audio pipe even though
> it is at niceness "0" and the make is at niceness "-20".  The music
> pipe is starved and ends up playing ~1 second bursts with ~1 second
> gap between bursts.  This seemed to have happened when I switched to
> the MPACI kernel from what was a uniprocessor lightly-edited GENERIC
> kernel.  (I can't switch back now to test as that would kill the
> compile.)
> 
> Is this a known MP kernel property?  Is there less granularity in the
> scheduler?
> 
> -wolfgang