Date: Tue, 23 Jan 2001 10:22:32 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, Dag-Erling Smorgrav <des@ofug.org> Subject: Re: Second zone allocator patch Message-ID: <20010123102231.Q26076@fw.wintelcom.net> In-Reply-To: <Pine.BSF.4.21.0101232315060.37252-100000@besplex.bde.org>; from bde@zeta.org.au on Tue, Jan 23, 2001 at 11:53:10PM %2B1100 References: <XFMail.010122194428.jhb@FreeBSD.org> <Pine.BSF.4.21.0101232315060.37252-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bruce Evans <bde@zeta.org.au> [010123 04:53] wrote: > 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. Correct me if I'm wrong... In 5.0 we actually have 3 states: 1) running 2) sleeping 3) blocked on a mutex Afaik, top half (user syscalls) can be in 1, 2 or 3. However interrupts should only be 1 or 3. The fact is that we really can't depend on mutual exclusion for much of _anything_ anymore, the only place I see mutual exclusion being useful is in the bottom half, but _only_ in hardware drivers, and only with thier private data, not counting useaccessable stuff (via ifconfig). Therefore the old trick of having 'non-blocking' code to provide interrupts with stable 'foo*' doesn't work anymore and mutexes are needed (or at least spinlocks), but even with spinlocks, you may still have an interrupt or user context come in on another CPU. There shouldn't be a problem with an interrupt blocking on a mutex. However there could be a problem if an interrupt stalls for too long because currently we only have a single interrupt thread per software interrupt class, if that gets stalled and happens to be the network thread we can't process any more packets in order to possibly free up the reasources needed. I think that, non-sleeping versions should continue to remain available. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20010123102231.Q26076>