From owner-freebsd-current@FreeBSD.ORG Sun Oct 18 11:24:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF84810657C0 for ; Sun, 18 Oct 2009 11:24:18 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 709938FC12 for ; Sun, 18 Oct 2009 11:24:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 6F5A310748 for ; Sun, 18 Oct 2009 20:24:16 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOt+7HpjdCka for ; Sun, 18 Oct 2009 20:24:08 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP for ; Sun, 18 Oct 2009 20:24:08 +0900 (JST) Date: Sun, 18 Oct 2009 20:24:07 +0900 From: Taku YAMAMOTO To: freebsd-current@freebsd.org Message-Id: <20091018202407.656c3863.taku@tackymt.homeip.net> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__18_Oct_2009_20_24_07_+0900_=nzbFP2nWWLmx7ap" Subject: softclock swis not bound to specific cpu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 11:24:18 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__18_Oct_2009_20_24_07_+0900_=nzbFP2nWWLmx7ap Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I noticed that the softclock threads didn't seem to be bound to any cpu. I'm not sure whether it's the Right Thing (TM) to bind them to the corresponding cpus though: it might be good to give the scheduler a chance to rebalance callouts. I'm about to test the modification like the attached diff. Comments are welcome. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Sun__18_Oct_2009_20_24_07_+0900_=nzbFP2nWWLmx7ap Content-Type: text/x-diff; name="softclock_bind.diff" Content-Disposition: attachment; filename="softclock_bind.diff" Content-Transfer-Encoding: 7bit --- sys/kern/kern_timeout.c.orig 2009-09-25 09:42:55.007102687 +0900 +++ sys/kern/kern_timeout.c 2009-10-18 19:47:15.537282684 +0900 @@ -201,6 +201,7 @@ start_softclock(void *dummy) { struct callout_cpu *cc; #ifdef SMP + struct intr_event *ie; /* This can be a member of callout_cpu. */ int cpu; #endif @@ -210,13 +211,15 @@ start_softclock(void *dummy) panic("died while creating standard software ithreads"); cc->cc_cookie = softclock_ih; #ifdef SMP + intr_event_bind(clk_intr_event, timeout_cpu); for (cpu = 0; cpu <= mp_maxid; cpu++) { if (cpu == timeout_cpu) continue; if (CPU_ABSENT(cpu)) continue; cc = CC_CPU(cpu); - if (swi_add(NULL, "clock", softclock, cc, SWI_CLOCK, + ie = NULL; + if (swi_add(&ie, "clock", softclock, cc, SWI_CLOCK, INTR_MPSAFE, &cc->cc_cookie)) panic("died while creating standard software ithreads"); cc->cc_callout = NULL; /* Only cpu0 handles timeout(). */ @@ -224,6 +227,7 @@ start_softclock(void *dummy) sizeof(struct callout_tailq) * callwheelsize, M_CALLOUT, M_WAITOK); callout_cpu_init(cc); + intr_event_bind(ie, cpu); } #endif } --Multipart=_Sun__18_Oct_2009_20_24_07_+0900_=nzbFP2nWWLmx7ap--