Date: Fri, 29 Oct 2004 23:51:22 -0500 From: Alan Cox <alc@cs.rice.edu> To: Mike Silbersack <silby@silby.com> Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <20041030045122.GK16728@cs.rice.edu> In-Reply-To: <20041029174131.A6530@odysseus.silby.com> References: <200410291910.i9TJAlNf089795@repoman.freebsd.org> <200410291549.17355.jhb@FreeBSD.org> <20041029174131.A6530@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 29, 2004 at 05:51:30PM -0500, Mike Silbersack wrote: > [snip] > > Instead, how about this - could per-CPU mutexes be implemented? In that > mode, mutexes wouldn't use atomic ops, because they'd only ever be used by > a specific processor, thereby eliminating the need for atomic ops. The > second modification would be that they set a per-CPU flag somewhere which > would tell the scheduler not to reawaken the sleeping kernel thread unless > it was on the same CPU it started on. In a word, yes. Start with the _get_sleep_lock macro from sys/mutex.h and make two changes: (1) inline the implementation of sched_pin() just before the _obtain_lock() call and (2) replace the current implementation of _obtain_lock() with a new implementation that is atomic with respect to interrupts but not other processors. A similar approach could be applied to unlock, starting with the _rel_sleep_lock() macro. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041030045122.GK16728>