Linked by Eugenia Loli on Thu 7th Apr 2005 02:04 UTC, submitted by David Rhodus
BSD and Darwin derivatives After many months of work DragonFly is about to release version 1.2 of its BSD based operating system. The first release candidate version can be download from dfly-20050406-pre1.2.iso.gz
Permalink for comment
To read all comments associated with this story, please click here.
Re: By Anonymous (IP: ---.dyn.iinet.net.au)
by Anonymous on Tue 12th Apr 2005 22:55 UTC

>The schemes preferred the Linux kernel where scalability
>is important are firstly per-CPU data structures where
>possible, then things like RCU and seqence/generation
>counting with read retry, atomic modification of data, etc.

Using per-CPU data is one of the methods rwatson and jbaldwin are testing to fine tune some of the subsystems that are now locked down.

http://www.freebsd.org/projects/netperf/

All of the methods you mention are very special purpose and could hardly be considered as a general locking strategy. Just good fits for certain scenarios.

>No. In Linux, you lock data, not code. And where locks are
>used, the focus is on having as narrow a hold width as
>possible.

I guess in linux the data just locks itself. What a nifty trick. For sure, the FreeBSD community could benifit from such a technique. Anyhow ... how do you have a lockless path in an SMP environment and still share resources? From what you have said, the shared resources ( i.e. the data structures ).

>Actually FreeBSD developers used to brag about having a
>working SMP implementation before Linux, which I think may
>have been true - if not then it would have been very close,
>definitely not "a lot longer".

Working is not optimal. Are you saying that removing the BKL was not at the top of the Linux 2.4.x priority list? During the same time period, removing GIANT was not a goal for the FreeBSD 4.x kernel. It is however a top goal for the 5.x kernel series. So, like I said before ... give it a chance. Different historical priorities, different timeline.

>And it's not about giving it a chance or not. It simply
>currently does not have a good SMP implementation.

As you keep stating. Its a lot easier to take pot shots at a system that is only half complete. Lets wait a bit and see how it all turns out. I think your going to be surprised to find out how well it finishes up. Even compared to what is turning out to be a very commercially backed kernel such as linux.