Messages in this thread |  | | | Date | Mon, 28 Sep 1998 07:28:54 -0600 | | From | yodaiken@chelm ... | | Subject | Re: [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/
|  |