Date: Thu, 22 Mar 2001 15:32:00 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Jacob <mjacob@feral.com> Cc: arch@FreeBSD.org Subject: Re: Critical Regions Round II Message-ID: <XFMail.010322153200.jhb@FreeBSD.org> In-Reply-To: <Pine.LNX.4.21.0103221510030.14792-100000@zeppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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.010322153200.jhb>