Skip site navigation (1)Skip section navigation (2)
From:      Rik van Riel <riel@conectiva.com.br>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Julian Elischer <julian@elischer.org>, Bill Huey <billh@gnuppy.monkey.org>, <freebsd-arch@freebsd.org>
Subject:   Re: New Linux threading model
Message-ID:  <Pine.LNX.4.44L.0209201831050.1857-100000@imladris.surriel.com>
In-Reply-To: <3D8B8E35.EDAF4450@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Sep 2002, Terry Lambert wrote:
> Rik van Riel wrote:

> > 1) per-cpu runqueues instead of a global one, which wants ...
> Yes.
>
> > 2) ... load balancer between these per-cpu queues
>
> No.
>
> This is the problem with the Linux model.  With an active load
> balancing algorithm, you end up with global contention for
> scheduler queue locks.

I'm not saying you should balance all the time.  It's enough
to load balance once every eternity, say 1/4 of a second.
Maybe a bit more often if you've got a really idle CPU.

> > 3) two runqueue arrays (current and expired) instead of
> >    just one, which enables ...
>
> Not required.
>
> > 4) ... event-driver priority recalculation, instead of
> >    recalculating the priority of each task separately
>
> This actually doesn't work.  The worst case failure is under
> overload, which is exactly where you don't want it to be.

What do you mean it doesn't work ?   This algorithm is
being used in practice and it works just fine.

> The scheduling for the BSD scheduler, as was pointed out, takes
> time not run into the priority weighting.

The Linux O(1) scheduler uses "time not on the run queue" to
determine process priority, this automatically scales when the
system gets busier and busier.

> A granularity of 3 seconds until the disctinction between the two queues
> for enqueueing delayed jobs is realized is really gross.  8-(.

Yes, it's gross.  However, if your system so heavily overloaded
that the sum of all timeslices of runnable processes gets larger
than 3 seconds there isn't much you can do about that.

kind regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september@surriel.com trac@trac.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44L.0209201831050.1857-100000>