Date: Thu, 24 May 2007 11:13:56 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Marcel Moolenaar <xcllnt@mac.com>, arch@freebsd.org Subject: Re: sched_lock && thread_lock() Message-ID: <200705241113.57372.jhb@freebsd.org> In-Reply-To: <20070523170449.L9443@10.0.0.1> References: <20070520155103.K632@10.0.0.1> <38601004-BB95-4B8B-87A6-26E2D52B89BA@mac.com> <20070523170449.L9443@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 23 May 2007 08:11:15 pm Jeff Roberson wrote: > 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. You have to have a spin lock with membar's across cpu_switch() so that curthread-private data is consistent after a thread migrates CPUs. You only really need it for migrations if all your migrations are explicit, in which case a per-CPU lock for a migration queue where both CPUs (old first, then new second) lock the lock during the handoff. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200705241113.57372.jhb>