lkml.org 
[lkml]   [1998]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: mmap() versus read()
Date
> 
> On Mon, Mar 09, 1998 at 01:46:14PM -0800, Perry Harrington wrote:
> > I still count in clock ticks. 35000 something IIRC last time I knew
> > for a fork()/clone(). Context switches are somewhat costly from what I've
> > heard too. FWIW, I have a P233MMX now, upgraded from a 486-120, the
> > cxtx switch on an x86 is much faster than other machines (from what I've
> > seen), probably from the TSS and builtin intel hacks. What and where are
> > you getting ~20usec? Anything will be fast on a 200mhz PPro, doesn't mean
> > that your 486-66 is going to rip Win95 a new ***hole.
>
> I've always been unable to understand the utility of kernel threads:
> perhaps you can explain it.

"Kernel threads" was a term (AFAIK) that was introduced with Solaris. It
actually has 2 meanings. In this audience, kernel thread means that the
kernel would implement a threading (multiple threads of execution in one
PID) abstraction that could be used within the kernel, or outside the
kernel, requiring a minimal userspace implementation of POSIX. Solaris
has diverged from the traditional way of making unix, and (AFAIK) runs as
a process unto itself. It does not have any real concept of a "sleep", but
rather has a "kernel thread" busy wait until the timer runs out. In this
context, a kernel thread is a thread of execution which runs inside the kernel,
independent of a user process. Solaris uses them all over the friggin' place,
for things that should really be true blocking calls. Traditional unix kernels
actually only run in the processing time of the *program*, that means that any
housekeeping is actually done in the time of the process. This of course is
except for interrupts. Linux uses an interrupt to perform scheduling functions
and hardware generated interrupts to actually communicate to the outside world.

In the strictest sense, Linux is diverging from a "true" unix if it uses
threads that run independent of the processing time of a process. Meaning,
they cannot be killed, and run with the kernel as their context. There
are legitimate uses for this (like the kswapd daemon and NFS, etc). Overuse
of kernel context threads is a bad thing(tm), because it soaks efficiency.

I was proposing that an abstraction like an LWP for solaris be created for
Linux. LWPs are lightweight in that they schedule, have a stack, a signal
mask, and a thread of execution. Right now, Linux uses clone() to make another
thread of exection which is essentially multiple processes with a shared
memory space. LWPs are abstract in that they run in the context of the
"process", but they do not have all of the controls of the "process". True,
a process is created with a single LWP bound to it, but that is more
intensive that just creating a stack, scheduler entity, and a signal mask.

Some will argue that clone() is just what I described, the fact is that it
still shows up separate processes, does not have a singular, merged, signal
path, and doesn't readily lend itself to fast implementations of thread
libraries. If Solaris can say, "just throw away a thread when you're done",
there is no reason why you shouldn't be able to say the same thing under
Linux (implying that throwing away a thread would be costly, because of
the overall creation, etc).

>
>
> > Pardon me if I seem a little confrontational, I'm not the only one who
> > sees clone() as costly. Also, compare these to Solaris thread creation
>
> Rob Pike pointed out that the solution to slow process creation is
> faster process creation, not another kernel abstraction.

I looked it over, it appears that this could benefit from pre-zeroed pages
of RAM. Solaris incidentally has a kernel thread which does defragmentation
and cleaning of system pages in the background. Ideally if this were
implemented, it could clean up a lot of other things and make them a lot
faster. Perhaps kswapd could do this???

>
> ---------------------------------
> Victor Yodaiken

--Perry

--
Perry Harrington Linux rules all OSes. APSoft ()
email: perry@apsoft.com Think Blue. /\

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.059 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site