Date: Wed, 23 May 2007 20:23:43 -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: <20070523202038.M9443@10.0.0.1> In-Reply-To: <15155940-CE7B-4E9F-9FD1-4C83A3EA5F48@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> <20070523170449.L9443@10.0.0.1> <15155940-CE7B-4E9F-9FD1-4C83A3EA5F48@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 May 2007, Marcel Moolenaar wrote: > On May 23, 2007, at 5:11 PM, Jeff Roberson wrote: > >>> 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. > > Yes, looks like it. > >>>> 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. > > Sounds like we want to keep ia64 in sync then. Please let me know > before you commit if you found the time, motivation, whatever to > include ia64 in the change or not. Either I want to test it or > I want to fix it ;-) I updated the patch at people.freebsd.org/~jeff/threadlock.diff Can you try this on ia64 marcel? You can try with 4BSD and ULE. ULE may not work if IPI_PREEMPT is not implemented however. I think it may be missing there. I changed the locks and asserts in pmap.c and moved over to the new sched_throw() interface. The other change in this diff is that I moved thread_lock_flags() into kern_mutex.c and fixed the thread locking loop so it is aware of td_lock transitions before it's successfully acquired a lock that may no longer be pointed at by the thread. This also removes the special case for blocked_lock and simply does the equivalent of a trylock() spin until it changes. Thanks, Jeff > > -- > Marcel Moolenaar > xcllnt@mac.com >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070523202038.M9443>