Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Feb 2005 14:47:42 -0800 (PST)
From:      "ALeine" <aleine@austrosearch.net>
To:        rwatson@freebsd.org
Cc:        freebsd-current@freebsd.org
Subject:   Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS  
Message-ID:  <200502062247.j16Mlg0r041149@marlena.vvi.at>

next in thread | raw e-mail | index | archive | help
rwatson@freebsd.org wrote: 

> I appreciate that not everyone is a fan of mutex synchronization,
> but "mutex hell" is a bit of an odd description: most bugs I see
> getting reported (and fixed) aren't even locking-related.  They're
> generally a property of lack of testing exposure for more obscure
> features or edge cases that are hard to test for without a wide
> testing base, such as edge-case hardware, bugs associated with
> longer run times, or a recently introduced feature, etc.

Well, mutex hell is more of a humorous description, but unfortunately
it is not too far from what is becoming a reality. I believe that
the path the FreeBSD Project has taken with the 5.x branch (not only
in regard to mutex locking but in general) has made things far too
complex in ways that make even seasoned hardcore developers such as
yourself unwilling to touch certain subsystems because only one or
two people really understand that system well enough to introduce
only a few (instead of a few dozen) critical bugs when changing that
subsystem. Or do you want to tell me that you could go right in and
get the critical section related stuff sorted out on your own without
John Baldwin and Stephan Uphoff in order to get to merge your UMA
related changes? :-)

I've been examining kernel sources in greater detail these past few
days and from what I've seen so far I believe certain subsystems
should just be rewritten from scratch in order to simplify things
in terms of solving MP problems and UP performance (burning a lot
of unnecessary cycles on every mutex release and the like is just
not acceptable, IMHO). Rewritting the IPI code and the scheduler
should be a good start, but I doubt anyone from the Core team would
even consider that because you've all invested so much into what
is in place now. As you keep working on the same things you've been
working on for years things get more and more complex and you become
more and more resistant to change, while potential developers become
more and more discouraged and in the end things might get very stale
with only a handful overworked developers who won't be able to see
the forest for the trees. I do not mean to start a flame war or
anything, this is just my opinion, I do have a lot of respect for
all of you guys working hard on the 5.x and the 6.x branches, I just
politely disagree with the direction in which the project is
heading. :-)

ALeine
___________________________________________________________________
WebMail FREE http://mail.austrosearch.net 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502062247.j16Mlg0r041149>