Date: Thu, 7 Mar 2002 14:45:04 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> 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>, "Jeroen C.van Gelderen" <jeroen@vangelderen.org> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <200203072245.g27Mj4Q70133@apollo.backplane.com> References: <XFMail.020307172045.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:You seemed to have missed the entire part where we handle deferred preemptions :in MI code in critical_exit(). The critical_enter/exit stuff really exists to :support the preemption code and to get rid of the various FOO_NOSWITCH flags. :I think it is ok to remove the linkage between critical_enter/exit and :cpu_critical_* (possibly even renaming cpu_critical_* to a better name) and to :allow arch's to optimize cpu_critical_* but leave critical_* as MI code. :That's what I've asked for from the start and Jake even suggested it from the :start. : :I'm still not comfortable with the optimiation, but changing the MI critical_* :code is by far my biggest objection to the code. : :John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ Who said anything about not handling deferred preemptions in MI code in critical_exit()? You mean just because I am moving less then 30 lines of code from MI to MD you object to the concept? What is so difficult about having the code, in the MD source files, do this: if (td->whatever_preemption_request) mi_function_to_deal_with_preemption(); We do this sort of thing all the time in MD code. It's useful because it allows us to focus a critical piece of code in a single source file rather then forcing us to split the critical piece of code into three or four source files as your current code does... all in the name of placing a bare 30 lines of code (less!) in kern/ instead of in <arch>/.../? Because in my view that is ALL you are talking about here... I don't see why the above code has to be in an MI procedure. It can just as easily be in an MD implementation of critical_*() and I believe the implementation of the API is far easier to work with and far more flexible with these two procedures sitting in MD rather then MI. I don't see how my code can possibly interfere with deferred preemption. Two lines of code in <arch> does not constitute interference, and I am certainly willing to deal with that myself... you don't have to lift one bloody finger. All you need to do is write your MI preemption handling code and you would have to do that in any case. Look at all the hacks you ALREADY have to deal with the split you impose between critical_*() and cpu_critical_*(). Look at the hack peter did and look at the incorrect assumptions you already have made in MI code due to the way you constructed the original API (hard interrupt disablement). And, most of all, I don't see how something so trivial should result in you vetoing my commit. I mean, it's no skin off your nose if down the line it turns out that critical_*() gets complex enough to warrent an MI split, because I would be the one doing it. But, right now, even with the preemption stuff you are talking about, there is NO REASON to keep a forced split and plenty of reasons to move it to MD. -Matt Matthew Dillon <dillon@backplane.com> 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?200203072245.g27Mj4Q70133>