Date: Tue, 23 Jan 2001 23:53:10 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.ORG> Cc: arch@FreeBSD.ORG, Dag-Erling Smorgrav <des@ofug.org> Subject: Re: Second zone allocator patch Message-ID: <Pine.BSF.4.21.0101232315060.37252-100000@besplex.bde.org> In-Reply-To: <XFMail.010122194428.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Jan 2001, John Baldwin wrote: > On 22-Jan-01 Bruce Evans wrote: > >> http://people.freebsd.org/~des/software/vm_zone-20010122.diff > >> > >> This replaces the simplelock in vm_zone with a mutex, and adds a > >> subsystem mutex that must be held when manipulating zlist (which is > >> now an SLIST). > > > > The simplelock was a spinlock, so changing it to a lock that can sleep > > changes the semantics. This seems to be a bug in the ZONE_INTERRUPT > > case -- note how the ZONE_INTERRUPT case of _zget() avoids locking > > stuff while the !ZONE_INTERRUPT case uses it. > > Blocking on a mutex is allowed in an interrupt context, just sleeping via a cv, > or tsleep/msleep is prohibited, so using a normal mutex should be fine here. > Note that it should still not call malloc() to avoid sleeping in the > ZONE_INTERRUPT case, however, it should lock in all cases. I meant "sleep" to mean "give up control". The difference is almost irrelevant here anyway. If the lock is held, mtx_enter() has to give up control to run the thread that is holding the lock, so that that thread can release the lock. That thread may also modify state which the original thread "knows" will not be modified because it is doing a non-blocking zalloc() or malloc() (the problem is more obvious for malloc() because the no-block flag M_NOWAIT is explicit). I think this means that non-blocking [mz]alloc()'s shouldn't exist in SMP systems. They would have to use spinlocks to work at all, but spinlocks should be avoided if possible. However, they should use spinlocks for now, so that we don't have to worry about them when pushing down the Giant lock. Bruce 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?Pine.BSF.4.21.0101232315060.37252-100000>