From owner-freebsd-current Wed Mar 6 15:16:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3D1FE37B404; Wed, 6 Mar 2002 15:16:41 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g26NGeF59131; Wed, 6 Mar 2002 15:16:40 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 15:16:40 -0800 (PST) From: Matthew Dillon Message-Id: <200203062316.g26NGeF59131@apollo.backplane.com> To: John Baldwin Cc: Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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_* I'm sorry John, I have no idea what you are refering to here. You have given no reference that I can lookup... you have hundreds of postings on arch. Why don't you just post the reasoning? Nothing I have seen anywhere so far would create an issue. I've heard you repeatedly reference documents but I have no idea which documents you are talking about or which portion of said documents you are refering to. So instead of continuing to post ghost references why don't you just lay the problem out as you see it in this thread and explain why you do not believe the critical section work I am doing would work with it. :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 We have very different development models, and different priorities. I'm not sure why you are attempting to impose your development model and priorities on me. This is the work I want to do. It's my time here, not yours, and if you believe that the work will make your job harder in some future unspecified commit then you have only to bring up the issue down the road when you are actually ready to work on that future unspecified commit and we can work it out. But I don't think it's appropriate for you to impose such a strict set of requirements based on work that does not exist in -current anywhere as far as I can tell. :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. Again, different development models. I see a set of APIs being severely misused by commits, the most recent being Peter's-that-he-backed-out, and I see a considerable need down the road for an efficient critical section API. You may not be interested in doing the work on these now but you != me. This work is my interest. Again, I don't understand why you are trying to impose your personal tastes on me. :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. I see an swi scheduler, which has nothing to do with the critical section work I have done. If there is other SWI stuff I don't see it in the -current tree. Nor does the work I have done in any way prevent the use of or in any way make it more difficult to use a list-based SWI queueing system instead of a bitmap. The bitmap stuff in my critical section patch only applies to i386... it's a specific implementation for soft and statclock IPI forwarding for the deferred case, nothing more. I didn't even bother to integrate AST (saving that for later work). It does not in any way prevent one from redoing that bit of code or even simply keeping the code and adding an SWI queue feature - something that could in fact be done either MD or MI depending on the needs of the architectures. If you believe there to be a problem here, perhaps explaining the SWI mechanism you are refering to would help. I am confident that it would not impose anything incompatible with the work I've done. :- 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 <>< http://www.FreeBSD.org/~jhb/ These fields do in fact belong in MD PCPU_MD_FIELDS. I didn't notice it, perhaps because there is not a single line of comment in sys/pcpu.h explaining what PCPU_MD_FIELDS was. There is in the i386 specific pcpu.h, but not in the main sys/pcpu.h header file and there should have been. This is about a 10 second change. I don't consider it all that significant and I will be happy to do it in the stage-2 commit. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message