[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Fri, 17 Mar 2006 22:38:22 +0100 CET
Waldemar Kornewald <wkornew@xxxxxxx> wrote:
> Axel Dörfler wrote:
> > I have to disagree. The locking model of the app_server is just not
> > very good :-)
> And good planning can keep all problems away. ;)
Definitely. This just hadn't been done for the app_server; the solution
to this problems is based on the refactoring Stephan and I did, but
it's just not implemented this way yet (as the current locking scheme
works very well for the moment). The new locking scheme will just allow
for a bit more concurrency.
> >> 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.
> What I meant is that because of CPU-affinity DragonFly's netstack can
> simplify its locking model (per-CPU globaldata structure). So, I
> fully
> agree (and that it's good for the cache).
Damn, you still didn't get it :-)
CPU affinity *can't* let you simplify your locking model. Only *locking
* a thread to a certain CPU can - but that's not a good thing, just an
IMO bad solution for a self-induced problem.
> Would thread-serialization-groups (every thread can be part of *one*
> serialization group, but switching between groups is allowed)? Like
> per-CPU data we could have per-group data. Only threads in the same
> group are serialized and when acquiring a token belonging to another
> group the thread temporarily switches its group (and thus unlocks his
> original group). This is just loud thinking, again. I've not yet
> thought
> this out and we probably need a radically different model, anyway.
Sure, you could have all sorts of things to improve the situation. OTOH
mutexes just give you that already, without any effort whatsoever on
your or my part :-)
> > > Maybe we can design something that does not have latency problems
> > > (or
> > > we can still consider STM)...that must be discussed for R2, at
> > > least.
> > Well, don't hold your breath :)
> > When we have a running stable system, we'll identify performance
> > bottlenecks by profiling - and if that should hint us the way to
> > something like that, so be it.
> Why performance? Productivity and reliability are my concern.
Both are not at all compromised by mutexes. At least it's your own
fault if it does :)
If you don't think about the performance of a basic solution like this
you're simply not thinking far enough, sorry.
Bye,
Axel.
Other related posts:
