Date: Tue, 05 Mar 2002 10:51:50 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Julian Elischer <julian@elischer.org>, FreeBSD current users <current@FreeBSD.org>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, Bosko Milekic <bmilekic@unixdaemons.com>, Alfred Perlstein <alfred@FreeBSD.org>, Terry Lambert <tlambert2@mindspring.com>, Bruce Evans <bde@zeta.org.au> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <XFMail.020305105150.jhb@FreeBSD.org> In-Reply-To: <200203010309.g2139DI40526@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >:> commit >:> 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 >:this >:stage I would rather avoid complex optimizations of APIs that may change in >:the >:future. There is more to be gained from locking subsystems. >:... >:John Baldwin <jhb@FreeBSD.org> <>< 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). > > -Matt > Matthew Dillon > <dillon@backplane.com> -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020305105150.jhb>