[openbeos] Re: Off-Topic: Con Kolivas quits Linux. He should know Haiku

  • From: "André Braga" <meianoite@xxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Fri, 10 Aug 2007 12:53:02 -0300

On 8/10/07, Salvatore Benedetto <emitrax@xxxxxxxxx> wrote:
> Because, as far as I understand, O(1) means that not matter how many
> processes are
> scheduled, the scheduler will always take the same amount of time to
> schedule the next processes
> (or thread).

Correct.

> Now, this look to me more as a hard real-time feature than a
> scheduler for Desktop. It might
> be efficient when you are working under heavy load, but at the same time,
> very inefficient when
> you only have few processes running, that's why I'm not a big fan of O(1)
> for Desktop. :)

This depends solely on the overhead that the algorithm imposes. Let's
suppose the overhead of the O(1) algorithm equals the overhead of some
O(f(n)) scheduler for some function "f". If "n" is small enough, say,
something between 5 or 10, I'd be perfectly happy with O(1).

What sucked about Linux's "first" O(1) scheduler is that said "n" was
close to 150, whereas it's between 6 and 10 for the CFS. Mine is close
to O(4), because I'm scheduling queues, not the threads directly.

> I can believe you can achieve 99%, but not 100% :)

We can if we focus on the goal of responsiveness ;)

But OK, I'll give that 1% to the micromanaging types ;D

> Could it be done without much changes in the scheduler ?

It can be done with *zero* changes to the scheduler; it's the
interface to make those changes that will necessarily suck.

For instance: ProcessController's interface will show you lots of a
very busy CPU meters, tons of threads and a dozen or so numbers
corresponding to symbolically defined default priorities. On the other
extreme, let's suppose we attach a "CPU resource" slider on every
windo that can be invoked by holding a key combo and clicking a window
title. How is that slider supposed to work? Which thread is going to
be the target, the busiest one at any given time or only one that's
associated to that window? What if the application logic is totally
separated from that window? Or is the whole team going to be affected?

Anyway... I'd rather get it right as far as the broader audience is
concerned and make available a ProcessController-like interface for
those so inclined. It's even done already :)

Other related posts: