Date: Wed, 23 May 2007 17:11:15 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Marcel Moolenaar <xcllnt@mac.com> Cc: arch@freebsd.org Subject: Re: sched_lock && thread_lock() Message-ID: <20070523170449.L9443@10.0.0.1> In-Reply-To: <38601004-BB95-4B8B-87A6-26E2D52B89BA@mac.com> References: <20070520155103.K632@10.0.0.1> <20070523155236.U9443@10.0.0.1> <6A9BD12D-D93C-4AE8-B4F4-D59A0327032D@mac.com> <20070523163109.X9443@10.0.0.1> <38601004-BB95-4B8B-87A6-26E2D52B89BA@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 May 2007, Marcel Moolenaar wrote: > >>> The old patch was missing PowerPC & ia64. Will the final version >>> include those as well? >> >> There are a couple of uses of the global scheduler lock in some >> architecture specific locations. They will continue to be safe with the >> 4BSD scheduler. I intended to work on these issues with the architecture >> maintainers after the threadlock patch goes in. Can you suggest some >> alternative to sched_lock for pmap_switch in ia64? > > pmap_switch() is called from cpu_switch() and from pmap_install(). > So, currently, pmap_install() grabs sched_lock to mimic the > cpu_switch() path and we assert having sched_lock in pmap_switch(). > Basically, any lock that serializes cpu_switch() would work, because > we don't want to switch the thread while in the middle of setting up > the region registers. We could simply use thread_lock() now if this serialization only applies to preventing multiple access to the same thread. > >> There are a couple of these small issues that should be perfectly safe that >> I was hoping to address outside of this patch so that it didn't get too >> big. > > I noticed you introduced sched_throw(). Would it harm if ia64 > doesn't yet use sched_throw() and instead has the sequence it > replaces? In other words: is the initial implementation of > sched_throw() the same as the current code? The problem is that sched_throw() must acquire the correct scheduler lock before entering cpu_throw(). That's why I moved it into the per-scheduler code. sched_smp, which is the updated ule, acquires the correct lock for the current cpu. Jeff > > -- > Marcel Moolenaar > xcllnt@mac.com >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070523170449.L9443>