Date: Mon, 26 Jun 2000 20:09:25 -0700 From: Joe Eykholt <jre@iprg.nokia.com> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: eischen@vigrid.com, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <39581AE5.C157F592@iprg.nokia.com> References: <200006270214.e5R2Exu13573@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Luoqi Chen wrote: > > > In regards to turnstiles, each kernel thread is born with its own > > turnstile. When it blocks on a mutex that doesn't have any waiters > > (no turnstile allocated to it), it uses the threads turnstile. If > > the mutex already has a turnstile (there are other waiters), then > > the threads turnstile is added to the system (per-CPU?) pool of > > turnstiles. When the thread wakes up and acquires the mutex, it > > takes a turnstile back from the turnstile pool. Turnstiles are > > also used for read/write locks. > > > > -- > > Dan Eischen > > > Does anyone know why a turnstile structure is used, instead of a sleep > queue embedded in the mutex structure? With cache line size of 16/32 > bytes, the latter seems to be more advantageous. Its basically for lock size, to keep the locks really small so each lock inside other structures wouldn't get too large. The cache line size doesn't matter so much as the size of the other structures that contain locks. But, if you make structures large (by including large locks in them) they won't fit in cache lines so well. In a fine-grained implementation, lots of small structures need locking. You only need turnstiles for the locks that are being waited on, but the turnstile can't be in the thread (or process) that's doing the waiting. There are a lot more mutexes and r/w locks than there are potential waiters, so its a big waste of space to have all the data per lock. The main thing is to not block on mutexes very frequently. The cost of blocking is secondary if the frequency is low enough. There are a lot of considerations and a lot of trial-and-error involved in getting a balanced (not perfect) implementation. Joe Eykholt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39581AE5.C157F592>