Linked by Thom Holwerda on Tue 30th Jan 2007 21:36 UTC, submitted by David Dengg
BSD and Darwin derivatives DragonFly 1.8.0 has been released. The biggest kernel change in this release is the addition of virtual kernel support and a virtual kernel build target. The biggest user-visible changes include updates to third party applications included in the base system, a major rewrite of NULLFS which removes all directory recursion restrictions from mount_null and removes nearly all the kernel resource overhead when using such mounts, and a multi-ip feature for jails.
Thread beginning with comment 207628
To view parent comment, click here.
To read all comments associated with this story, please click here.
CaptainPinko
Member since:
2005-07-21

So did FreeBSD abandon the M:N threading model? That would be a shame after all the work that went into it. Then again: if you must then you must. Where can I find more information about this? Wikipedia doesn't seem to mention this more does the KSE homepage. Did I misread your comment?

Reply Parent Score: 2

kaiwai Member since:
2005-07-06

It was mentioned on a FreeBSD quartly report a while back in regards to KSE and slow performance on non-x86 architectures.

One has to ask how much is due to KSE tuning beant towards a particular architecture, or are the architecturers were there is bad performance, just plain well crap architecture.

Reply Parent Score: 3

butters Member since:
2005-07-08

So did FreeBSD abandon the M:N threading model? That would be a shame after all the work that went into it.

Everybody is moving away from M:N. It's a bad idea that looks good on paper. Solaris and AIX both support M:N, and Linux can use it with NGPT (not the same at NPTL), but it is not the default on any of these systems.

Basically, threading only works efficiently if the kernel "knows" about all of the user threads. For example, in M:N (and M:1), it is possible for one blocking thread to block one or more of its peer threads, even if they are runnable. With increases in physical memory and addressable memory (with 64-bit systems), there is no excuse for the kernel to delegate thread management to userspace.

Reply Parent Score: 3