Date: Wed, 06 Mar 2002 17:43:19 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.ORG>, Julian Elischer <julian@elischer.org> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <XFMail.020306174319.jhb@FreeBSD.org> In-Reply-To: <200203051715.g25HFsk60359@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05-Mar-02 Matthew Dillon wrote: > >:> 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. > > Those are your cycles, not mine. Why should I be forced to sit on my > heals > for an unknown period of time (but so far 3 weeks waiting for the ucred > changes and 2 weeks waiting for critical_*()), twiddling my thumbs > wasting > MY cycles just because of your own scheduling issues? > > That's really the crux of this whole situation. I don't think it is > appropriate for you to impose your development methodology on me or > anyone else, and I most especially do not think it is appropriate for > you to arbitrarily hold off the hard work that I have done in order > to fit it into your schedule. > > I have said very clearly what I intend these critical_*() patches to > do. I have said, repeatedly, that I do not believe they would > intefere with your work in any significant manner. You have yet to > explain in any detail why you think they would. I have said, > repeatedly, that I am perfectly willing to work with you later on > when you ARE ready to move forward on your own work. > > That's the crux of the situation, John. I do not believe you have > the right to hold this work off, at least not based on any of the > explanations you have given so far. Have you read the paper I posted to arch? It quite clearly (I thought) explained the role of the critical_* and the cpu_critical_* in the preemption code. It should be rather obvious from that why I don't want the critical_* stuff to change from their current model. I also think that just as it is too early to optimize to light weight ithread switches (sparc64 is going to optimize all kthread switches, not just ithreads by using a more general approach, and we may do that on other arch's as well) it is too early to optimize and add complexity for certain API's when we aren't sure what effect they will really have on the final product. For example, right now Giant blocks almost all of the kernel so we are going to contest it on almost every case. Contesting involves grabbing the sched_lock which can result in executing the critical section implementation more than we will end up doing later. I would rather wait on optimizations until the system is farther along and we can judge what things really need optimization and which ones don't. Optimizations are usually a tradeoff as far as increased complexity vs. performance and I personally at least would like to keep things simple for the time being. However, I would not be opposed to the code if it fit into the design in the document I posted to arch. A couple of notes though based on a quick preliminary glance at the code: - The swi code has been changed to not be limited to a bitfield so that it can support an arbtirary number of swi's. Right now we still support a small number but we may end up with several netisr's for example. We also may move away from scheduling netisr's via swi_sched anyways and using a semaphore or some such instead. Presently your patch goes back to assuming a fixed number of SWI's. - More of a minor niglet that is easy to be fixed: you added MD fields to the MI pcpu bits of struct pcpu. MD fields belong in the PCPU_MD_FIELDS macro in sys/i386/include/pcpu.h. If you intend for the fields to be MI, then that is more of a problem as it assumes too much about interrupts for different platforms. Alpha interrupts will not easily fit into a simple bitmask for example. -- 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.020306174319.jhb>