Date: Thu, 16 Nov 2000 14:42:59 -0800 From: Jake Burkholder <jburkhol@home.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: smp@FreeBSD.ORG, cp@bsdi.com, jake@io.yi.org Subject: Re: cvs commit: src/sys/kern kern_timeout.c Message-ID: <20001116224259.DC1E6BA7A@io.yi.org> In-Reply-To: Message from John Baldwin <jhb@FreeBSD.ORG> of "Thu, 16 Nov 2000 13:26:57 PST." <XFMail.001116132657.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On 16-Nov-00 John Baldwin wrote: > > jhb 2000/11/16 13:20:53 PST > > > > Modified files: > > sys/kern kern_timeout.c > > Log: > > The recent changes to msleep() and mawait() resulted in timeout() and > > untimeout() not being called with Giant in those functions. For now, > > use the sched_lock to protect the callout wheel in softclock() and in > > the various timeout and callout functions. > > > > Noticed by: tegge > > Big Kudos to Tor for finding this! Using the sched_lock here is more or less a > bandaid for now. A possible long-term solution might be to use a dedicated > sleep lock to protect the callout wheel. However, if you do this, then you > can't be holding a spinlock when you call into timeout and friends. If we add > in a lock to protect teh sleep queues, then we might be able to push sched_lock > further down into msleep() and mawait(), so that we don't need sched_lock until > after we call timeout and before we call untimeout, but I'm still thinking > about this. Does anyone else have any ideas? One thing I am worried about is > whether the overhead of the extra locks involved (sleepqueue locks, probably > process locks (but we will need those anyway), and a callout wheel lock) will > end up negating the performance gain from not having sched_lock protect so many > different things. I think we need a separate spin lock for the callout wheel, ala BSD/OS's callout_mtx. Hardclock looks at the callout wheel and is now a fast interrupt, so it can't acquire a sleep mutex. Its a little paranoid because hardclock doesn't actually traverse any lists, it just checks if the current callout bucket is empty, and potentially schedules softclock, but you could miss a very short timeout on an smp system. ticks could also get incremented in the middle of softclock's test for if the callout's time has come. I have patches that do this and make softclock INTR_MPSAFE, I just need to test them. There's actually another major problem with this. The run queue and sleep queue use the same list linkage in struct proc, so its not safe to release sched_lock while you're on the sleep queue. If the process blocks on giant in CURSIG, the sleep queue will get corrupted. We really need to split the run queue/sleep queue linkage. Jake > > -- > > John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message 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?20001116224259.DC1E6BA7A>