[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: Waldemar Kornewald <wkornew@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Fri, 17 Mar 2006 18:35:26 +0100
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. ;)
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).
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.
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.
Bye,
Waldemar
Other related posts: