Friday, February 04, 2000 12:21 AM
Rik van Riel <riel@nl.linux.org> wrote :
> > > Why not
> > >
> > > if ((c <= 0) && (nr_running >= smp_num_cpus)) /* To fix better */
> > >
> > > and define smp_num_cpus to 1 if case of UP system? [I think it already
> > > _is_ defnied like this...]
> >
> > 100% agree.
>
> That is a very bad plan. It would mean that the priority
> of processes isn't recalculated during a period of low
> cpu load.
>
> That means that your running background process will have
> a high priority when your needing-cpu-once-in-a-while
> interactive task needs the CPU.
>
> It also means that the priority of your interactive task
> is lower than what it should be and that the priority of
> the interactive task is higher than what it should be,
> leading to worse interactive performance.
>
> At least, that's what I think it does. I'd love to see
> some test results from someone with enough time on their
> hands -- you probably need about 3 days to fully explore
> a scheduler and notice all of the strange things that
> might happen...
>
> (I've created a nice scheduler patch and it has taken me
> some 3 days before I noticed one strange side effect of
> the patch, even though I'd really done my best to try and
> create as much different workloads as possible)
Hi Rik,
Your observation is right, It's an old bug fixed into the 2nd version of the
patch that also contain
a better tasks distribution inside clusters.
If someone want the patch simply ask me, coz I don't want to fall into
another long discussion
about the need or not of a scheduler change.
Cheers,
Davide.
-- Feel free, feel Debian !- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:10 EST