Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Nov 2000 18:24:59 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        julian@elischer.org (Julian Elischer)
Cc:        arch@FreeBSD.ORG, smp@FreeBSD.ORG
Subject:   Re: Threads (KSE etc) comments
Message-ID:  <200011211824.LAA27595@usr08.primenet.com>
In-Reply-To: <3A1A2A26.4CF0B849@elischer.org> from "Julian Elischer" at Nov 20, 2000 11:54:14 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> CC's trimmed,
> 
> which group should stay? SMP or ARCH?

ARCH is chartered for the discussion, SMP is where the work is
actually geting done.  I think that's the reason for the
original poster to cross-post.

I'll let clearer heads prevail by picking where to sent their
response.


> there is no reason why ANY KSEG need sto be limitted to one KSE
> by the kernel unless there is only one CPU.
> The PTHREAD_SCOPE_PROCESS, KSEG may have one or more KSEs
> assigned to it depending
> on whether the UTS wants to create more or not....
> 
> Thinking about what Terry said, I guess you could have M>N
> (M KSEs, N CPUs) in a KSEG, but I don't think it would be 
> useful to do so.

It lets me have M simultaneous blocking operations outstanding;
it's only not useful in the context of KSEGs.

I guess we could arrange it this way:

(1 KSE, 1 KSEG), (M KSEGs, N CPUs)

This should make it more obvious: I want M quanta from N CPUs.
Or in other words, I want to compete as M porcesses on this N
CPU system.

The reason for this is to allow me to control my own interleave;
for example, if we look at the "team" or "ddd" programs, both of
which use interleaved I/O using multiple processes to improve
overall throughput, we see an application where I _do not_
want 2 quanta for 3 threads, with 2 of the threads bound to only
one of the quanta: doing that will lose me 25% of my throughput.

If you want to visualize the scheduling order, think of a three
element braid (braids are neat: the simplest is a three element,
and you can think of it as a graph of FIFO queue, two elements
at a time).

If there is equal work, then the work on each of two elements is
going to complete in alternating order, which means that if you
have a third element waiting, it will be alternately assigned
(ideally; KSEGs break this).

I think that perhaps the best use of threading is to try to
interleave I/O to ensure against I/O binding.  KSEGs seem to
be designed with the idea that the threaded application is
CPU, not I/O bound, which is where I think the mistake lies.


> > > One gross hack might be to limit the number of total KSEs to
> > > the number of permitted child processes for a given process,
> > > but I'd hesitate to encourage people to use the not generally
> > > exposed and non (POSIX) standard interfaces that would be
> > > needed for a process to try to do this automatically.
> > 
> > You have to be careful with terminology.  If we're going by
> > what Jason has defined in his paper, the KSEG is the entity
> > that has the quantum, not the KSE.  So the KSEGs would be
> > limited to the permitted number of child processes.
> 
> yes, but that gives the ability to use M times as much CPU as a
> nonthreaded process.

If you won't give it to me, I'll just take it, instead, either
by using rfork() and a shared memory segment for my global data,
which gets me the equivalenet of a threaded environment, for all
practical purposes, or I'll just fork() and run multiple instances
of myself.  Either way, you don't get to tell me not to compete
as multiple processes, and I can throw a KSEG based policy out the
window, without needing your permission to do it.  Worse, there
is additional context switch overhead introduced by this (the
same reason Linux kernel threads are a bad idea), and everyone
gets to pay the penalty for my application.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011211824.LAA27595>