From owner-freebsd-arch Thu Mar 22 15:32:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 6836337B71B for ; Thu, 22 Mar 2001 15:32:35 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2MNW9G89289; Thu, 22 Mar 2001 15:32:09 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 22 Mar 2001 15:32:00 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: Critical Regions Round II Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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? 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). > 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. >> Hopefully this will make everyone happy. >> >> Prior to SMPng we had the following functions related to interrupts: >> >> disable_intr() - x86 only and just did a 'cli' >> enable_intr() - x86 only and just did a 'sti' >> >> With the initial SMPng commit this was added to to allow nested disabling >> of interrupts: >> >> save_intr() - return current interrupt state >> restore_intr() - revert to previously read interrupt state >> >> Thus one would do: >> >> u_int foo; >> >> foo = save_intr(); >> disable_intr(); >> .... >> restore_intr(foo); >> >> Also, this entire API was forced out into MI code. After the discussion on >> the mailing list I propose the following that will hopefully make everyone >> happy: >> >> disable_intr() - x86 / ia64 only, just clears the IF or psr.i bit, and is >> a MD function >> enable_intr() - x86 / ia64 only, just sets the IF or psr.i bit, and is a >> MD function >> >> save_intr() - gone >> restore_intr() - gone >> >> critical_enter() - enters a critical region of code that must not be >> preempted >> critical_exit() - leaves a critical region of code >> >> The critical_enter/exit functions use an opaque type 'critical_t' for the >> value that critical_enter() returns that must be passed to critical_exit(). >> Thus, the above code now becomes: >> >> critical_t foo; >> >> foo = critical_enter(); >> ... >> critical_exit(foo); >> >> This API includes the same optimizations mentioned for the Alpha as the >> last proposal. A manpage for critical_enter/exit is attached. >> >> > -- John Baldwin -- 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