Re: [PATCH] scheduler patch, faster still

yodaiken@chelm.cs.nmt.edu
Mon, 28 Sep 1998 07:28:54 -0600

On Mon, Sep 28, 1998 at 11:01:43AM +0200, Rik van Riel wrote:
> > I must have missed these results. What I saw were microbenchmark results
> > with no kernel profiling and no explanation. Why should searching a
> > queue of 10 on 586 take any significant time? Where is the time spent?
>
> There is only one place where it _can_ be spent (the scheduler
> is quite simple) and that is at scanning the run_queue.

One of the reasons that Linux is such a delightful operating system is
that your type of "reasoning" has usually been ignored.

> > I'm very skeptical of loose use of the term RT. Are these tasks of yours
> > really RT? Hard? Soft? Statistical?
>
> They are fairly hard and are triggered from an interrupt. After

"Fairly hard" means absolutely nothing at all.

> the interrupt enters the machine, the RT tasks should respond
> as fast as possible. There's a certain area where processes and

"as fast as possible" -- see above.

> > How? It's quite simple as it is.
>
> Reducing overall simplicity is not the goal. The main goal

Coulda fooled me.

Bye.

-- 


---------------------------------
Victor Yodaiken
Department of Computer Science
New Mexico Institute of Mining and Technology
Socorro NM 87801
Homepage		http://www.cs.nmt.edu/~yodaiken
PowerPC Linux page	http://linuxppc.cs.nmt.edu
Real-Time Page		http://rtlinux.org




-
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/