:Once the mutexes are in place the underlying implementation can
:change pretty easily from task switching always to only task
:switching when the mutex is owned by the same CPU that I'm running
:on. (to avoid spinlock deadlock)
That makes *NO* *SENSE* Alfred! So the first step is to introduce
every single possible feature under the sun, requiring massive reworking
of the code, even if it means the system becomes massively unstable,
inefficient, and starts crashing and burning, and then only *later* we
remove the features that don't pan out? That is the development model
you are using for -current?
:I agree that task switching _might_ be a performance hit, however
:that can be fixed by only task switching when in interrupt context.
WILL be a performance hit. WILL introduce major bugs. IS unnecessary,
DOESN'T make any sense whatsoever, is at CROSS PURPOSES with goals
already stated (not having any serious contention in the first place),
REQUIRES massive changes to the code with not a chance in hell of
producing an equivalent performance improvement for the trouble.
There is no 'remains to be seen' here Alfred. This is setting up
-current for a fall, one that could be entirely avoided *now*
if you people would sit down and start thinking about what you are
Remember when Dyson introduced ten thousand cool things all at once
and didn't debug them? Remember how long it took DG to the system
back into some semblence of shape after that? Remember that, even after
all that hard work, there were still literally hundreds of hard to find
bugs that DG couldn't find that it took Alan, DG, and I a year's worth
of work beyond all the work DG had already done to cleanup? Is that
what you want to happen to current? Because that is where current is
headed right now.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message