From owner-freebsd-arch Thu Mar 22 15:47: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3813137B71C; Thu, 22 Mar 2001 15:47:03 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA17127; Thu, 22 Mar 2001 15:47:07 -0800 Date: Thu, 22 Mar 2001 15:47:02 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Critical Regions Round II In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Mar 2001, John Baldwin wrote: > > On 22-Mar-01 Matthew Jacob wrote: > > > > critical_enter/critical_exit seem fine, but you can save yourself some > > compiler space by just having it return a void *. > > So far critical_t is a register_t on all arch's it is implemented on so far. > Well, it probably should be a register_t, I think I'm using __uint32_t and > the like right now: > > x86: > /* Critical section value */ > typedef __uint32_t critical_t; > > alpha: > /* Critical section value */ > typedef __uint32_t critical_t; > > ia64: > /* Critical section value */ > typedef __uint64_t critical_t; > > Hrm, is a ldq any different from a ldl to the alpha? Umm... yup... 8 bytes instead of 4... > If ldq is faster I could > make it be a register_t (and thus a __int64_t). I'll probably change it to > register_t on x86 and ia64 as it simply holds the saved value of a register > (eflags on x86, psr on ia64). I don't think the speed is an issue either way. > > > 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 > > > > I believe that this actually is possible. > > 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. Hmm, and x86 profiling, though again, that can use critical_*. > Kernel x86 profiling with SMP is broken in lots of interesting ways. Let's put it this way...if I have to solve what appear to be obscure bugs by disabling interrupts in the alpha MD code somewhere, I'll instantiate such a function (again) if it's no longer there. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message