Date: Fri, 23 Mar 2001 18:26:05 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: arch@FreeBSD.org, Matthew Jacob <mjacob@feral.com> Subject: Re: Critical Regions Round II Message-ID: <XFMail.010323182605.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0103231817520.17960-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Mar-01 Bruce Evans wrote: > On Thu, 22 Mar 2001, John Baldwin wrote: > >> On 22-Mar-01 Matthew Jacob wrote: >> > What's wrong with alpha having >> > >> > disable_intr() calls MD/platform function that disables >> > mainbridge >> ints >> > enable_intr() calls MD/platform function that enables mainbridge ints > > 1. Someone might use them in MI code if they have generic names like that. > 2. The MD versions might be a little different from the MI versions and > from each other, so they should have different names. > >> That's fine, however, with this change, disable/enable_intr() are actually >> called in very few places. Mostly in trap() on x86 due to hacks to work >> around >> Cyrix bugs, and in configure(). Everything else uses critical_*. >> >> Well, the joy driver needs fixing (it should use critical_*) as does the >> bktr >> driver. The x86 pcvt driver is also obnoxious, but its x86 specific, and >> the >> pc98 spkr and dma drivers should be using critical_* so that they work in a >> nested fashion. > > Most of these drivers show how not to use disable_intr(). I think most > of them should have used splhigh(). The translation of splhigh() to > SMPng is mtx_lock*() plus maybe giving the driver a realtime priority, > not critical_enter(). Ok. Hmm, the only things that I think really need critical_enter() would be some of the i386 cpu init stuff and drivers that use fast interrupt handlers? I can actually provide a list of things that use critical_enter/exit now that can be at least converted to splfoo(). Actually, the joy driver only uses disable/enable_intr on x86 and uses splfoo() on the alpha, though I think it really does need critical_enter/exit, as it uses while doing the actual inb's on the joy data port. Although, I'm not sure how well that will work on SMP where a fast interrupt could always trigger on another CPU while the first CPU is in a driver. Using a spinlock would make this work as far as protecting the shared data in question, but then you have the CPU getting the interrupt spinning in a loop until the other CPU releases it. I guess this is how it works in 4.x for fast interrupts though. >> Hmm, and x86 profiling, though again, that can use critical_*. >> Kernel x86 profiling with SMP is broken in lots of interesting ways. > > Profiling for all arches currently needs to use something both more > and less than critical_*: > - more, because the profiling state is shared between all CPUs. I guess > disabling interrupts will be sufficient when profiling works properly > under SMP. I don't see how call graphs can work if calls for all CPUs > are recorded in the same profiling state. Hmmmm. This will need to use per-CPU profiling state then, unless we are going to destroy all parallelism in the kernel in the profiling case. :( > - less, because critical_* should be subject to profiling, so it can't > be called from profiling code. They are static inlines, though, correct? So they shouldn't be calling mcount? Or am I wrong about inlines and mcount? Also, I think I may have a somewhat ugly way of fixing the SMP mcount_enter/mcount_exit. (side note) > Profiling can easily use MD interfaces for locking since what it uses is > defined by the MD macros MCOUNT_DECL(), MCOUNT_ENTER() and MCOUNT_EXIT(). > > Bruce -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010323182605.jhb>