From owner-freebsd-smp Sat Nov 18 23:50: 6 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (h24-69-199-88.gv.shawcable.net [24.69.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 643A837B479 for ; Sat, 18 Nov 2000 23:50:01 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 84FA1BA7A for ; Sat, 18 Nov 2000 23:50:00 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 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 In-Reply-To: Message from Jake Burkholder of "Sat, 18 Nov 2000 22:02:33 PST." <200011190602.WAA98532@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Nov 2000 23:50:00 -0800 From: Jake Burkholder Message-Id: <20001119075000.84FA1BA7A@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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