lkml.org 
[lkml]   [2000]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SCO: "thread creation is about a thousand times faster than onnative


On Fri, 25 Aug 2000, dean gaudet wrote:
> On Fri, 25 Aug 2000, Jamie Lokier wrote:
>
> > There are a couple of really obvious states where you don't need to
> > record the full path to where we slept.
> >
> > - The schedule() in ret_from_sys_call.
> >
> > - do_poll().
> >
> > The first is used when pre-empting, such as when we have lots of threads
> > running. The second is used by almost every task that sleeps, including
> > heavy duty servers.
>
> hmm, if i'm writing a heavy duty server that uses enough kernel threads to
> start worrying about the number of stacks in use, then i'm probably not
> calling poll(). i'm probably blocking in disk/net reads/writes directly.
> i'd only be using poll() if i'm doing userland threads/state-machines.

That's not the problem.

I think what Jamie is overlooking is all the details.

For example, take the really obvious one: sure, you don't need a kernel
stack under some circumstances.

What are you going to do when you DO need one?

Allocate one dynamically?

Good-bye performance.

That's why I said "Show me the code". I'm rather unconvinced that you can
actually get the details right without huge amounts of complexity.

I'm sure it could be done. I'm pretty convinced that there is no way to do
it efficiently.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.120 / U:1.016 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site