On 01-Mar-02 Matthew Dillon wrote:
>:On 28-Feb-02 Matthew Dillon wrote:
>:> Not to put too fine a point on it, but, I don't see how this can
>:> possibly justify preventing me from committing my critical_*() stuff.
>:> You've just stated publically that your preemption stuff is unusable
>:> as it currently stands. Why am I supposed to wait an arbitrary period
>:> of time for you to fix, test, and commit it?
>:> I would REALLY like to commit my critical_*() stuff, and for the record
>:> this will also include the stage-2 stuff described in the original
>:> comments that will be made a few days after the current commit.
>:Because the critical_* changes you are doing don't match up to the overall
>:design. See my mail to -arch for more on that though. At some point in the
>:future I think that this work can fit in rather well to the cpu_critical_foo
>:stuff (which can be split out from critical_enter/exit now). However, at
>:stage I would rather avoid complex optimizations of APIs that may change in
>:future. There is more to be gained from locking subsystems.
>:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
>:"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
> I strongly disagree. I have yet to see any technical description of
> this so-called overall design that shows any incompatibility, and what
> I decide to do with my time is my business. I don't really care
> whether you are ready for 'optimizations' or not. I seem to recall
> that you had similar objections when I started pushing Giant into the
> system calls, yet that work is in hind sight an obvious enabler for
> other work people have been doing and committing.
No, I actually requested that Giant be pushed down into the syscalls and Maxime
Henrion is working on finishing that work right now.
> I decided to address a serious issue that I've had with those routines
> for months because you consistently refused to even entertain the
> notion that you may have constructed the API wrong. Frankly, I feel
> that these changes both optimize and properly abstract the critical_*()
> code. I strongly believe that the abstraction you have in there now is
> improper. My patches have been tested, they work, and they ARE going to
> be committed as soon as I am able to do so. I believe you are
> overstepping your bounds as a committer by attempting to scrap them
> and I also believe that you do not fully understand the implications
> of the code, because you are blinded by the notion that I am making
> adjustments to your API. But I do, BDE does, Julian does, as do others.
> To me these changes are essential, and they must go in now before
> even more hacks are committed to the codebase to get around existing
> limitations. There are already hacks in the trampoline/fork_exit
> and ast code that seriously pollutes the MD/MI boundry, all of which
> you've flicked off your shoulder and explained away as being allowed
> by your API, and Peter added a third hack with his pmap commit (which
> got backed-out when he backed out the commit). These hacks make it
> crystal clear to me that you critical_*()/cpu_critical*() API is
> seriously flawed. I am addressing the issue and cleaning up the hacks
> to create a proper MD/MI separation of the code.
Actually, I responded saying that I was willing to talk about how to properly
abstract CRITICAL_FORK (which is gross I admit). If you will read the design
doc, you will see that actually critical_foo and cpu_critical_foo can now be
safely split up and made independent of each other. To this extent td_critnest
would still stay MI, but td_savecrit could end up going away if the MD code
fully handles the saving/restoring the state for whatever cpu_critical_* become.
> It makes no sense whatsoever to me to be told not to commit something
> due to stale code that may not be quite compatible sitting in P4 that
> you can't make work in any reasonable time frame. You should stop
> trying to screw over my work and instead look to your own. You have
> so many balls in the air constructed in a fine mesh that you can't seem
> to accept a single change to your perfectly meshing subsystems, half
> of which are going stale in P4. This is greatly restricting your
> ability to consider deviation.
*sigh* The only reason I'm not spending my cycles tracking down the preemption
bugs so that preemption can go in is that I have decided that at the moment
there is more gain to be found by doing actual locking work. This means that
preemption will eventually go in, just Not Right Now. To that extent, I don't
think premature optimizations based on observations of a kernel locked entirely
by Giant that alter the API's preemption will change (and that were originally
introduced when I committed all the bits of the preemption code that I could
w/o breaking the kernel) should go in.
> I will repeat, if you want to discuss specific technical issues related
> to these commits after I put them in, I am all ears. I will repeat, I
> see nothing in this code that prevents you from accomplishing anything
> that you've brought up to date (which so far as just been the non-working
> preemption code you have sitting in P4).
> Matthew Dillon
> <[EMAIL PROTECTED]>
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message