lkml.org 
[lkml]   [1998]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateMon, 28 Sep 1998 07:28:54 -0600
From yodaiken@chelm ...
SubjectRe: [PATCH] scheduler patch, faster still
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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2010