OSNews

Raised some very good points about scalability. Is there anyone here who can point me to a Multex vs threadcentric paper comparing the two techniques?

There is some stuff about it on the dragonfly website www.dragonflybsd.org. I can't see how they're really different to any other sort of mutual exclusion lock. Slightly different sementics perhaps. Result is you can't have more than one thread in a critical region at a time.

There is some stuff about it on the dragonfly website www.dragonflybsd.org. I can't see how they're really different to any other sort of mutual exclusion lock. Slightly different sementics perhaps. Result is you can't have more than one thread in a critical region at a time.

Hmm maybe I'm wrong. Further digging found this:
http://www.dragonflybsd.org/docs/BAFUG1_SLIDES/img8.html

I wonder if he's going to try to use this model for as much high level stuff as possible?

>Raised some very good points about scalability. Is there >anyone here who can point me to a Multex vs >threadcentric paper comparing the two techniques?
before anything you should know what is a thread : it is a computing unity inside a processus. A processus may have more than one thread running in parallel.
Threads may share some data. What would happened if two thread use the same data at the same time ?? Kaboom !
So you can specify this data as mutex.
Each time a thread need to use the data, it check if the data is locked, if yes it wait, else it locks it for its own use and proceed it. Finaly, it unlocks the mutex so i'll usable by other thread.
If I understand right, the thread centric approch is to have no data in common, so no locking, but to allow the threads to communicate via some messenging system, so they can share some information.
Hope I am not to far from the truth!
Alex

Thank you for the links, from what it appears, the dragonflybsd team are trying to make BSD simplier to make it possible to add more features without adding more complexity to the equation. Sounds like a great idea and hopefully some other projects pick up on this idea.

Maybe he should contact Genesi, and get his OS to work on Pegasos? :-)

3. What is the primary goal of dragonfly, servers or desktops?
Matthew Dillon: Both.


dfBSD is heading for the user base since now has nvidia drivers support.


What better than a daemon with sneakers?
A daemon with sneakers and wings

if they are going for desktop use i hope they implemenent some sort of user-level package installation. If they are going to innovate they might as well do it here too.

There is some discussion of a new package management system on the dfBSD home page. From my understanding that there will be some extensive innovation. There home page is definately worth browsing.

dfBSD is heading for the user base since now has nvidia drivers support.

Err, how so? Where?

Matt has been a prolific coder for many years and is an unsung hero in free software.

As a long time FreeBSD user at work I welcome a new option at the precipitous juncture from FreeBSD 4 to 5. One more resource for novel, peer reviewed ideas and implementations.

It will be interesting to see how DragonFly will fare with the growing dominance of linux in the free OS sphere. The linux talent roster is very full and it is difficult to get attention for ideas and implementation. That one value of the BSD projects - a project you can get in on the ground floor.

>>Linux obviously has the eye of the masses

I guess that would be qualified as "geek masses", cause windows has the eye of the unwashed masses...

;-)

informative interview.

Well, it's using FreeBSD native one with the patches.

http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/dfports/x11/nvidia-d...

I have been using DragonFly on and off for a while now, and for the most part it's been very nice for day to day use. It's fast, and it can handle whatever loads I can throw at it. The scheduler needs work however. Some things that have never caused jerkyness in things I was doing in the foreground (like rebuilding the system in the background etc.) can sometimes be painfull in DragonFly. It's not consistent, nor am I expecting such from a pre-beta OS, but I thought I'd mention it anyway.

DragonFly also builds slower than does FreeBSD 4 or 5, largely due to the inclusion of two versions of GCC. I'm sure that they'll drop GCC 2.95.x soon, but until then, it takes just barely more than twice as long as it used to.

They include directions to manually install DragonFly on the Live CD, and I've wondered what has stopped them from reworking it into a small handful of shell scripts so that relative newbies could install it more easilly, without having to spend ages waiting for whatever the final implementation will evolve into. It should take someone like Matt maybe a couple of hours (if that!) to do so, and the benefits would be great enough IMO to put the real work on hold for that few hour period.

I am very much looking forward to DragonFly's first release, and if they have the desire to sell copies of it on CDs, I will most definately buy one.

As far as I knew DragonFly was still using the standard (mostly) FreeBSD 4.x scheduler.

Having followed DragonFly pretty closely for around 6 months, I can't say I've noticed any of these scheduler issues. My p2-450 can buildworld in the background, and if not for limited disk bandwidth I'd never know it was there. It does not skip my music, or anything like that. You might want to make sure you have DMA enabled on your hard drive.

That said, there have been a number of problems that have gotten in my way -- the most significant I think being the package situation. Many FreeBSD ports/packages no longer build or install properly on DragonFly. This is an issue that will get worked on soon I hope.

Overall DragonFly feels very snappy to me.

I'm very sure that it could have been the particular snapshots I was using at the time, but that in itself does not mean that the scheduler doesn't need work. I'd considder myself about the biggest fan of DragonFly there is right now, but that's not going to stop me from pointing out flaws I find, sporadic as they may be (aren't pre-release OSs great! .

As to the ports collection, I've had mostly successes, except a few core X related ones. FreeBSD packages so far have offered me no headaches. I would very much like to see a greatly expanded dfports tree however. It will come.

It's always great to hear about DragonFly, I'm really looking forward to a stable release... Perhaps soon it will replace my FreeBSD 4.9 boxes

Getting the GUI to run isn't a problem, and has little
to do with the kernel. Oh, DragonFly isn't just a kernel?
So what, it's not like they are going to develop their
own entire GUI.

The difference is throughput vs. responsiveness (interactivity). On the "server" it costs you (in throughput)
if you are too heavily weighted towards "interactivity".
On the "desktop" it's the reverse.

No, you cannot have the best of both worlds. When I log into
my "server" it SHOULD keep high throughput and my interactive
(shell) process should not get the kind of response it needs
on the desktop.

IMHO!!

There are of course many many areas where better desktop
performance IS the same as better server performance, eg
threads scalability. But my point is that the answer to
the question leaves something to be desired.

No, you cannot have the best of both worlds. When I log into my "server" it SHOULD keep high throughput and my interactive (shell) process should not get the kind of response it needs on the desktop.

Don't be a dumbass. There are two things that would allow one to have the best performace for both types of systems. You could have more than one scheduler and use whatever one best suits your needs (Linux does this), or you could have (better yet) an adaptive scheduler that modifies it's behavior as needed.

It is your thinking that leaves something to be desired. There are few things in this world that we cannot eventually do. Having an OS that can work out of the box as either a server or as a desktop isn't one of those things that we will be denied.

Learn to think.

Its a new project and all new projects deal with those issues, nothing new.

He keeps saying AMD cmpatiible with AMD, when in reality it is the other way around. Get th egacts straight please!

He did get it right; Intel's new 64 bit line (not Itanium) will be made to be compatible with AMD64, not the other way around.

our unattainable goal (which I hope actually winds up being attainable) is to develop DragonFly into a transparently cluster-capable system implementing native SSI (Single System Image). It is something that no non-commercial system today can do (the type of clustering Linux supports isn't even close to the type of clustering that we have as our goal, and clustering has never been one of the other BSD's goals as far as I can tell).


I would suggest a look at http://www.openssi.org/ , which is SSI clustering for Linux. Soon DRBD will be integrated and then you can have a high availability shared root without shared disk hardware. (At the moment, shared disk hardware is still required for HA -- but not if you only want a non-HA shared root)

That is off topic here. Also, unlike what is being done with DragonFly BSD, OpenSSI is now, and always will be a tacked on grotesque hack to make Linux do things that it was never intended to do, and will likely never be modified to do correctly.

Please stop trolling here, this is a DragonFly article.

I know that you are just trolling, but hey, you might also be a retard, so I'll try to enlighten you a little.

The SMP approach being undertaken in DragonFly is essentially lockless, meaning that it works without using mutexes. As FreeBSD 5.x is very heavilly into the fine grained mutex thing, it would have taken much more time and effort for Matt to have implemented the lockless SMP in DragonFly if he had of started with 5.x. Simple logic really, start off with a system that has fewer mutexes to begin with, and you'll have fewer mutexes that will eventually need to be removed.

YeeHaw!

The jerkyness I spoke of ages ago when this story first came up was fixed today. Matt found some issues in kern_fork.h and a couple other files that was causing newly forked processes to have realtime priority until they were rescheduled. I've just rebuilt (for the second time today) and the laggyness that I expereinced before is now gone.

All is well with the world. ;-)