[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: