Date: Sat, 18 Nov 2000 23:50:00 -0800 From: Jake Burkholder <jburkhol@home.com> To: smp@freebsd.org Subject: Re: cvs commit: src/sys/alpha/alpha machdep.c src/sys/i386/i386 machdep.c src/sys/ia64/ia64 machdep.c src/sys/kern kern_clock.c kern_intr.c kern_mutex.c kern_timeout.c src/sys/sys callout.h Message-ID: <20001119075000.84FA1BA7A@io.yi.org> In-Reply-To: Message from Jake Burkholder <jake@FreeBSD.org> of "Sat, 18 Nov 2000 22:02:33 PST." <200011190602.WAA98532@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> jake 2000/11/18 22:02:33 PST
>
> Modified files:
> sys/alpha/alpha machdep.c
> sys/i386/i386 machdep.c
> sys/ia64/ia64 machdep.c
> sys/kern kern_clock.c kern_intr.c kern_mutex.c
> kern_timeout.c
> sys/sys callout.h
> Log:
> - Protect the callout wheel with a separate spin mutex, callout_lock.
> - Use the mutex in hardclock to ensure no races between it and
> softclock.
> - Make softclock be INTR_MPSAFE and provide a flag,
> CALLOUT_MPSAFE, which specifies that a callout handler does not
> need giant. There is still no way to set this flag when
> regstering a callout.
make -j 64 buildworld on SMP still ends up with a stuck process here.
All the makes were in "select" last time, which passes PCATCH to
tsleep, so its probably the msleep/CURSIG thing. grr.
I didn't move the callout initialization because it would end up
wasting some amount of memory if callwheel and callfree were just
malloc(9)ed. With maxusers at 64 the callfree pool is about 75K and
the callwheel is 32K, so malloc will allocate 128K and 32K
respectively. Is this worth worrying about?
I'd like opinions on the best way to allow MPSAFE callouts
to be registered. There's alot of code that uses the timeout
and callout_{reset,stop} interfaces, so I guess it'll be
another rename the function and provide a compatibility macro.
If possible new code should use the callout_* functions which
allows the callout structure to be allocated by the caller.
This is a pain:
panic("timeout table full");
BSD/OS does some nasty lock gyrations to deal with dynamically
allocating callouts in the timeout function, which is not allowed
to fail, so I don't know if we want to go there.
sched_cpu(), roundrobin() and endtsleep() are some timeout driven
functions that could probably be made MPSAFE relatively easily.
sched_cpu() is almost safe because of sched_lock, the traversal
of allproc is the main reason for still needing Giant. BSD/OS
uses a lockmgr lock to protect allproc, which seems like a good
idea to me, despite the controversy over reader/writer locks.
Many of the traversals are read-only, so a shared/exclusive lock
would let them run concurrently.
Jake
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?20001119075000.84FA1BA7A>