[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: "Joseph Liu" <froseph@xxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Fri, 17 Mar 2006 09:11:10 -0500
Great, in looks like we have a consensus on FreeBSD. Hopefully work
will commence soon.
On 3/17/06, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
>
> > > The fact that lwkt a) can't interrupt threads unconditionally while
> > > having a token, and b) that it locks them to a single CPU is both
> > > not a
> > > good solution. It doesn't allow for for short latency thread
> > > scheduling
> > > for one - only for interrupts. IOW they should only be used for
> > > very
> > > short critical zones - then they actually have an advantage over
> > > disabling interrupts and acquiring a spinlock.
> > I agree that under certain circumstances latency could be a big
> > problem
> > (e.g.: waiting for data from a device), but how often do you have
> > huge
> > transactions and how often is it impossible to split that into
> > multiple
> > concurrent (and asynchronous) transactions? In many cases we can work
> > around the problem by sending messages. Also, Joseph already said
> > that
> > DragonFly's netstack rarely uses tokens, at all (probably because of
> > CPU-affinity).
>
> Maybe it didn't go through, but CPU *affinity* is a good thing - just
> not if you lock a thread to a single CPU. CPU affinity helps to improve
> cache usage.
The idea is that you can migrate lwkts between cpus so that you can
build a scheduler on top of lwkt which micromanages the migration of
threads betweens cpus. You build a scheduler for userland threads on
top of lwkt scheduler: http://kerneltrap.org/node/4370
The only way I can see being unable to interrupt a thread with tokens
is if the interrupt reqires the tokens. The only other part of api is
critical sections which tell the interrput thread to reschedule after
the critical section is over. Just wondering I have a misconception
somewhere and what your thoughts are on the subject.
Cheerio,
Joe
Other related posts: