From owner-freebsd-smp Sun Jan 13 0:21:23 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id D581E37B417 for ; Sun, 13 Jan 2002 00:21:19 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id D00FD10DDFB; Sun, 13 Jan 2002 00:21:18 -0800 (PST) Date: Sun, 13 Jan 2002 00:21:18 -0800 From: Alfred Perlstein To: smp@freebsd.org Subject: won't boot. Message-ID: <20020113002118.N7984@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hey, remeber that box that won't boot for me? Dual Tyan 2510? Well I can get into the debugger, and here's what I see: ~Stopped at siointr1+0xb1: jmp siointr1+0x1b7 db> t siointr1(c1468000,c04771c0,0,c03c5d23,64a) at siointr1+0xb1 siointr(c1468000) at siointr+0x23 Xfastintr4() at Xfastintr4+0x34 --- interrupt, eip = 0xc023826c, esp = 0xdc777ce0, ebp = 0xdc777ce0 --- critical_exit(0,dc777d18,c0227a0c,c041d420,0) at critical_exit+0x24 _mtx_unlock_spin_flags(c041d420,0,c03a31f0,22e) at _mtx_unlock_spin_flags+0x71 ithread_loop(c6734880,dc777d48,c6734880,c0227830,0) at ithread_loop+0x1dc fork_exit(c0227830,c6734880,dc777d48) at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 32 dc79a500 dc7a3000 0 0 0 0000204 6 irq8: rtc 31 dc79a800 dc79f000 0 0 0 0000204 6 irq0: clk 30 dc79ab00 dc79b000 0 0 0 0000204 6 irq4: sio0 29 da57ff00 dc792000 0 0 0 0000204 2 swi0: tty:sio 28 da580200 dc78e000 0 0 0 0000204 6 irq6: fdc0 27 da580500 dc78a000 0 0 0 0000204 6 irq1: atkbd0 26 da580800 dc786000 0 0 0 0000204 2 irq11: sym1 25 da580b00 dc77f000 0 0 0 0000204 6 irq10: sym0 24 da580e00 dc778000 0 0 0 0000204 3 usbevt c6721a10 usb0 23 da581100 dc774000 0 0 0 0000204 2 irq9: ohci0 22 da581400 dc76f000 0 0 0 0000204 6 irq15: ata1 21 da581700 dc76b000 0 0 0 0000204 6 irq14: ata0 20 da581a00 dc767000 0 0 0 0000204 6 irq5: fxp1 19 da581d00 dc762000 0 0 0 0000204 6 irq3: fxp0 18 da582000 dc75d000 0 0 0 0000204 2 swi3: cambio 17 da582300 dc759000 0 0 0 0000204 6 swi2: camnet 16 da582600 dc755000 0 0 0 0000204 6 swi5: task queue 15 da582900 dc751000 0 0 0 0000204 3 sleep c042e860 random 14 da582c00 dc74d000 0 0 0 0000204 6 swi4: vm 13 da582f00 dc749000 0 0 0 000020c 2 swi6: tty:sio clock 12 da583200 dc745000 0 0 0 0000204 6 swi1: net 11 da583500 da590000 0 0 0 000020c 2 idle: cpu0 10 da583800 da58c000 0 0 0 000020c 2 idle: cpu1 1 da583b00 da588000 0 0 0 0000200 1 swapper 0 c03fd940 c0532000 0 0 0 0000200 3 conifhk c0402d60 swapper Any clues? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 4:10:30 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 2983D37B404; Sun, 13 Jan 2002 04:10:20 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 091C410DDFC; Sun, 13 Jan 2002 04:10:20 -0800 (PST) Date: Sun, 13 Jan 2002 04:10:20 -0800 From: Alfred Perlstein To: John Baldwin Cc: smp@freebsd.org, dillon@freebsd.org, tanimura@freebsd.org Subject: Re: fd locking. Message-ID: <20020113041019.P7984@elvis.mu.org> References: <20020112191645.J7984@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020112191645.J7984@elvis.mu.org>; from bright@mu.org on Sat, Jan 12, 2002 at 07:16:45PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Alfred Perlstein [020112 19:17] wrote: > * John Baldwin [020112 19:00] wrote: > > > In svr4_stream.c, do_putmsg and do_getmsg should be taking a thread not a proc > > as their first argument and callers should be fixed as well. > > Can this be delayed? Done. > > You might consider a file_init() and file_destroy() function or macro like so: > > Can this be delayed? I personally don't see the need for this, but if you want to do it I'm ok with it. No objections. > > Hmm, do you think you could change fdalloc() to take a filedesc * instead of a > > thread so it's clearer when you lock the old filedesc that it is being used? > > Might work, Can this be delayed? This can't work, we need the proc pointer to enforce open file limits. The limits are stored in the rlimit struct hung off the proc. > > Bruce is going to not like you for adding nested includes of sys/lock.h and > > sys/mutex.h. Instead, add nested includes of sys/_lock.h and sys/_mutex.h, and > > then add sys/lock.h and sys/mutex.h to the files that need them. > > Can this be delayed? I'll start on this. > > Other then that it looks great. Can you clean these bits up and post a new > > patch for folks to test. Aside form svr4, the current patch should be good for > > testing as well. Esp. need people with SMP machines to test this stuff. We'll get that now. :) > I still need to fix Matt's fd holding stuff, but I'm anxious to get this > in before I loose it all to some massive structure renaming or whitespace > run like I have before. :) I have to look at the fget* stuff now as well. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 5: 8:39 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 92C8237B402; Sun, 13 Jan 2002 05:08:36 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 7A18110DDFC; Sun, 13 Jan 2002 05:08:36 -0800 (PST) Date: Sun, 13 Jan 2002 05:08:36 -0800 From: Alfred Perlstein To: smp@freebsd.org Cc: jhb@freebsd.org, dillon@freebsd.org Subject: making malloc(9) smp safe? Message-ID: <20020113050836.Q7984@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Malloc has its own mutex, however when it needs to do page allocations via kmem_malloc() it drops the mutex and calls it. kmem_malloc() needs giant. what do I do? Do I grab giant before calling malloc(9)? Do I make malloc(9) aquire or recurse on giant automatically? (basically grab giant around kmem_malloc() call in malloc(9)) ? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 5:28:11 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id A77C237B404; Sun, 13 Jan 2002 05:28:07 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 82DC610DDFC; Sun, 13 Jan 2002 05:28:07 -0800 (PST) Date: Sun, 13 Jan 2002 05:28:07 -0800 From: Alfred Perlstein To: John Baldwin Cc: smp@freebsd.org, dillon@freebsd.org, tanimura@freebsd.org Subject: Re: fd locking. Message-ID: <20020113052807.R7984@elvis.mu.org> References: <20020112191645.J7984@elvis.mu.org> <20020113041019.P7984@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020113041019.P7984@elvis.mu.org>; from bright@mu.org on Sun, Jan 13, 2002 at 04:10:20AM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Alfred Perlstein [020113 04:10] wrote: > * Alfred Perlstein [020112 19:17] wrote: > > * John Baldwin [020112 19:00] wrote: > > > > Bruce is going to not like you for adding nested includes of sys/lock.h and > > > sys/mutex.h. Instead, add nested includes of sys/_lock.h and sys/_mutex.h, and > > > then add sys/lock.h and sys/mutex.h to the files that need them. > > > > Can this be delayed? > > I'll start on this. Ugh, what a pain! Basically I wind up with an annoying problem. I want fhold and fhold_locked to be inlines. However they use mutexes, _however_, they aren't used for the most part, __however__ a lot of people include these files... so basically this is hard to do: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundary=2 ../../../dev/sound/isa/ad1816.c In file included from ../../../dev/sound/pcm/sound.h:49, from ../../../dev/sound/isa/ad1816.c:29: ../../../sys/file.h: In function `fhold_locked': ../../../sys/file.h:152: warning: implicit declaration of function `mtx_assert' ../../../sys/file.h:152: `MA_OWNED' undeclared (first use in this function) ../../../sys/file.h:152: (Each undeclared identifier is reported only once ../../../sys/file.h:152: for each function it appears in.) ../../../sys/file.h: In function `fhold': ../../../sys/file.h:163: warning: implicit declaration of function `mtx_lock' ../../../sys/file.h:164: warning: nested extern declaration of `mtx_assert' ../../../sys/file.h:165: warning: implicit declaration of function `mtx_unlock' ugh. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 9:30:45 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 1C4A337B41A for ; Sun, 13 Jan 2002 09:30:37 -0800 (PST) Received: (qmail 14329 invoked from network); 13 Jan 2002 17:30:35 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Jan 2002 17:30:35 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020113050836.Q7984@elvis.mu.org> Date: Sun, 13 Jan 2002 09:29:56 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: RE: making malloc(9) smp safe? Cc: dillon@freebsd.org, smp@freebsd.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jan-02 Alfred Perlstein wrote: > Malloc has its own mutex, however when it needs to do page allocations > via kmem_malloc() it drops the mutex and calls it. > > kmem_malloc() needs giant. > > what do I do? > > Do I grab giant before calling malloc(9)? For now, yes. Hmm, let me think though. Can you get away with doing it for malloc but not free? People call free with locks held, but they don't call malloc with locks held, so... > Do I make malloc(9) aquire or recurse on giant automatically? > (basically grab giant around kmem_malloc() call in malloc(9)) This might be ok, just don't go calling malloc with locks held still. :) > ? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "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 From owner-freebsd-smp Sun Jan 13 9:36: 0 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 9A4D037B41E for ; Sun, 13 Jan 2002 09:35:52 -0800 (PST) Received: (qmail 10191 invoked from network); 13 Jan 2002 17:35:51 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Jan 2002 17:35:51 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020112191645.J7984@elvis.mu.org> Date: Sun, 13 Jan 2002 09:35:11 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: fd locking. Cc: tanimura@freebsd.org, dillon@freebsd.org, smp@freebsd.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Jan-02 Alfred Perlstein wrote: >> In svr4_stream.c, do_putmsg and do_getmsg should be taking a thread not a >> proc >> as their first argument and callers should be fixed as well. > > Can this be delayed? They are system calls, so they are really getting a thread not a proc (well, the functions that call them are syscalls). These are KSE conflicts. If you've fixed them already that is good, but if not it's pretty quick to do. :) >> You might consider a file_init() and file_destroy() function or macro like >> so: >> >> void >> file_init(struct file *fp) >> { >> >> mtx_init(&fp->f_mtx, "struct file", MTX_DEF); >> fp->f_count = 1; >> } >> >> void >> file_destroy(struct file *fp) >> { >> >> mtx_destroy(&fp->f_mtx); >> } >> >> I would just make file_destroy a macro for now. Having file_init a function >> would save a little space since the "struct file" string wouldn't be >> duplicated, but you can always change it later. You could add more stuff if >> needed as well. :) > > Can this be delayed? It's not required, it's just cleaner, esp. if we switch to a new slab allocator since these functions will almost fit in perfectly to such a beast. >> hmm, for this code: >> >> + mtx_init(&fp->f_mtx, "file structure", MTX_DEF); >> + fp->f_gcflag = 0; >> fp->f_count = 1; >> fp->f_cred = crhold(p->p_ucred); >> fp->f_ops = &badfileops; >> fp->f_seqcount = 1; >> + FILEDESC_UNLOCK(p->p_fd); >> + sx_xlock(&filelist_lock); >> + FILEDESC_LOCK(p->p_fd); >> if ((fq = p->p_fd->fd_ofiles[0])) { >> LIST_INSERT_AFTER(fq, fp, f_list); >> } else { >> LIST_INSERT_HEAD(&filehead, fp, f_list); >> } >> p->p_fd->fd_ofiles[i] = fp; >> + FILEDESC_UNLOCK(p->p_fd); >> + sx_xunlock(&filelist_lock); >> if (resultfp) >> *resultfp = fp; >> if (resultfd) >> >> You could xlock filelist_lock earlier before the first FILEDESC_LOCK with >> associated changes to avoid as many locking operations. You wouldn't keep >> the >> xlock held for much longer and it would probably be quicker in the long run. > > Yes, but those codes call malloc with M_WAITOK, if someone was to close > a filedescriptor i may get deadlock because they block on the filehead > sx lock while i'm blocked in malloc and i already have the filedesc lock. No, not that early, you get the FILEDESC_LOCK a few lines earlier, and you could lock the xlock right before that, but after the malloc. >> Bruce is going to not like you for adding nested includes of sys/lock.h and >> sys/mutex.h. Instead, add nested includes of sys/_lock.h and sys/_mutex.h, >> and >> then add sys/lock.h and sys/mutex.h to the files that need them. > > Can this be delayed? Well, now you won't know what headers to remove unless you start going around with phk's script. Much easier to get this right the first time. >> Other then that it looks great. Can you clean these bits up and post a new >> patch for folks to test. Aside form svr4, the current patch should be good >> for >> testing as well. Esp. need people with SMP machines to test this stuff. > > New patch up: > > http://people.freebsd.org/~alfred/fd.diff I see you've committed it already, so I'll just test the code in the tree now. You really need to get it tested by SMP prior to commit since a UP box just isn't going to see the same races, and now if you have a bug that hoses current, we all get to live with it until it's fixed. :-P > I still need to fix Matt's fd holding stuff, but I'm anxious to get this > in before I loose it all to some massive structure renaming or whitespace > run like I have before. :) Start using p4 since it handles this for you better. It's not hard or anything. :-P -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "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 From owner-freebsd-smp Sun Jan 13 10:23:53 2002 Delivered-To: freebsd-smp@freebsd.org Received: from hotmail.com (f266.law11.hotmail.com [64.4.16.141]) by hub.freebsd.org (Postfix) with ESMTP id 8964A37B400 for ; Sun, 13 Jan 2002 10:23:48 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 13 Jan 2002 10:23:48 -0800 Received: from 217.136.64.147 by lw11fd.law11.hotmail.msn.com with HTTP; Sun, 13 Jan 2002 18:23:48 GMT X-Originating-IP: [217.136.64.147] From: "Andrei Mihalcea" To: freebsd-smp@FreeBSD.org Subject: NEED HELP PLZ Date: Sun, 13 Jan 2002 18:23:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jan 2002 18:23:48.0240 (UTC) FILETIME=[7174F100:01C19C5F] Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hy, i've a tyan tiger s2460 dual athlon motherboard, with two thunderbirds 1.4Ghz, a ati radeon 64ddr, 256 corsair ddr ecc registered memory, a maxtor 40GB 133 over a promise ultra133 tx2 controller, a realtek lan and a crystal sound card. My big problem is that i've many problems when i activate the smp support into the kernel (apic), when i try to make install of xfree or kde, the processus stop and i have a error 1 (sometimes core dumped), from now ago 3 days i try every possibility in my bios, into the kernel (apm, apic, scsi, xxx) and that don't work, is that normally ? Is it an incompatibility behind bsd and my motherboard (bios) ? Is that because i run two thunderbirds and not mp cpus ? Please help me... Thanks, i tryed the 4.5rc1 version. _________________________________________________________________ Discutez en ligne avec vos amis, essayez MSN Messenger : http://messenger.msn.fr/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 11:20:15 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 4A4B937B402 for ; Sun, 13 Jan 2002 11:20:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020113192008.GLBY10951.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sun, 13 Jan 2002 19:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA72753; Sun, 13 Jan 2002 11:02:15 -0800 (PST) Date: Sun, 13 Jan 2002 11:02:14 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: smp@freebsd.org Subject: Re: won't boot. In-Reply-To: <20020113002118.N7984@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org try adding "show locks" On Sun, 13 Jan 2002, Alfred Perlstein wrote: > Hey, remeber that box that won't boot for me? > > Dual Tyan 2510? > > Well I can get into the debugger, and here's what I see: > > ~Stopped at siointr1+0xb1: jmp siointr1+0x1b7 > db> t > siointr1(c1468000,c04771c0,0,c03c5d23,64a) at siointr1+0xb1 > siointr(c1468000) at siointr+0x23 > Xfastintr4() at Xfastintr4+0x34 > --- interrupt, eip = 0xc023826c, esp = 0xdc777ce0, ebp = 0xdc777ce0 --- > critical_exit(0,dc777d18,c0227a0c,c041d420,0) at critical_exit+0x24 > _mtx_unlock_spin_flags(c041d420,0,c03a31f0,22e) at _mtx_unlock_spin_flags+0x71 > ithread_loop(c6734880,dc777d48,c6734880,c0227830,0) at ithread_loop+0x1dc > fork_exit(c0227830,c6734880,dc777d48) at fork_exit+0x9c > fork_trampoline() at fork_trampoline+0x8 > db> ps > pid proc addr uid ppid pgrp flag stat wmesg wchan cmd > 32 dc79a500 dc7a3000 0 0 0 0000204 6 irq8: rtc > 31 dc79a800 dc79f000 0 0 0 0000204 6 irq0: clk > 30 dc79ab00 dc79b000 0 0 0 0000204 6 irq4: sio0 > 29 da57ff00 dc792000 0 0 0 0000204 2 swi0: tty:sio > 28 da580200 dc78e000 0 0 0 0000204 6 irq6: fdc0 > 27 da580500 dc78a000 0 0 0 0000204 6 irq1: atkbd0 > 26 da580800 dc786000 0 0 0 0000204 2 irq11: sym1 > 25 da580b00 dc77f000 0 0 0 0000204 6 irq10: sym0 > 24 da580e00 dc778000 0 0 0 0000204 3 usbevt c6721a10 usb0 > 23 da581100 dc774000 0 0 0 0000204 2 irq9: ohci0 > 22 da581400 dc76f000 0 0 0 0000204 6 irq15: ata1 > 21 da581700 dc76b000 0 0 0 0000204 6 irq14: ata0 > 20 da581a00 dc767000 0 0 0 0000204 6 irq5: fxp1 > 19 da581d00 dc762000 0 0 0 0000204 6 irq3: fxp0 > 18 da582000 dc75d000 0 0 0 0000204 2 swi3: cambio > 17 da582300 dc759000 0 0 0 0000204 6 swi2: camnet > 16 da582600 dc755000 0 0 0 0000204 6 swi5: task queue > 15 da582900 dc751000 0 0 0 0000204 3 sleep c042e860 random > 14 da582c00 dc74d000 0 0 0 0000204 6 swi4: vm > 13 da582f00 dc749000 0 0 0 000020c 2 swi6: tty:sio clock > 12 da583200 dc745000 0 0 0 0000204 6 swi1: net > 11 da583500 da590000 0 0 0 000020c 2 idle: cpu0 > 10 da583800 da58c000 0 0 0 000020c 2 idle: cpu1 > 1 da583b00 da588000 0 0 0 0000200 1 swapper > 0 c03fd940 c0532000 0 0 0 0000200 3 conifhk c0402d60 swapper > > Any clues? > > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductable donations for FreeBSD: http://www.freebsdfoundation.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 From owner-freebsd-smp Sun Jan 13 12:43:28 2002 Delivered-To: freebsd-smp@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 1110937B417; Sun, 13 Jan 2002 12:43:20 -0800 (PST) Received: from pool0417.cvx40-bradley.dialup.earthlink.net ([216.244.43.162] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16PrT7-0003aC-00; Sun, 13 Jan 2002 12:43:05 -0800 Message-ID: <3C41F153.DCA0A4F3@mindspring.com> Date: Sun, 13 Jan 2002 12:42:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: smp@freebsd.org, jhb@freebsd.org, dillon@freebsd.org Subject: Re: making malloc(9) smp safe? References: <20020113050836.Q7984@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alfred Perlstein wrote: > Malloc has its own mutex, however when it needs to do page allocations > via kmem_malloc() it drops the mutex and calls it. > > kmem_malloc() needs giant. > > what do I do? > > Do I grab giant before calling malloc(9)? > Do I make malloc(9) aquire or recurse on giant automatically? > (basically grab giant around kmem_malloc() call in malloc(9)) > > ? The way Dynix does this (see UNIX Internals: The New Frontiers, Uresh Vahalia, Chapter 12 Kernel Memory Allocation, 12.9 A Hierarchical Allocator for Multiprocessors) is to seperate the memory into a global pool, and per CPU pools, with a seperate Coelesce-to-Page layer. Here are some nice papers: http://www.research.ibm.com/K42/full-hotos-01.ps http://citeseer.nj.nec.com/mckenney96selecting.html http://citeseer.nj.nec.com/54799.html http://citeseer.nj.nec.com/bonwick94slab.html http://citeseer.nj.nec.com/wilson95dynamic.html http://citeseer.nj.nec.com/gamsa99tornado.html Yyou can get a copy of the original paper: "Efficient Kernel Memory Allocation on Shared-Memory Multiprocessors" P.E. McKenney, J. Slingwine Processdings of Usenix, Winter, 1993 (p295-305). Paul's current email address is: pmckenne@us.ibm.com (he works in the Linux Technology Center at IBM Watson Research). You can get the mother of all papers on SMP kernel memory allocation from his home page at: http://www.rdrop.com/users/paulmck He has quite a nice set of papers on SMP, locking, and memory allocation. Here is another paper he's been involved with recently; it's also quite applicable to the problem at hand: http://lwn.net/2001/features/OLS/pdf/pdf/read-copy.pdf -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 13:10:41 2002 Delivered-To: freebsd-smp@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 4B89037B400; Sun, 13 Jan 2002 13:10:34 -0800 (PST) Received: from pool0417.cvx40-bradley.dialup.earthlink.net ([216.244.43.162] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Prth-0000Q5-00; Sun, 13 Jan 2002 13:10:33 -0800 Message-ID: <3C41F7C7.C9B71A98@mindspring.com> Date: Sun, 13 Jan 2002 13:10:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein , smp@freebsd.org, jhb@freebsd.org, dillon@freebsd.org Subject: Re: making malloc(9) smp safe? References: <20020113050836.Q7984@elvis.mu.org> <3C41F153.DCA0A4F3@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert wrote: > You can get a copy of the original paper: > > "Efficient Kernel Memory Allocation on Shared-Memory > Multiprocessors" > P.E. McKenney, J. Slingwine > Proceedings of Usenix, Winter, 1993 (p295-305). > > http://www.rdrop.com/users/paulmck PS: I've recently been told that I sometimes appear to be "really out there", when in my own mind, I've laid out the dots, and done everything but connect them for the reader with a big, black magic marker to show them the picture of the pony. So, in case anyone missed my subtle irony here... This paper is hosted on a box at a well known FreeBSD shop, along with several other important papers in this area, as well as the home page of the person who is the recognized authority for this type of thing (Paul McKenney), and he's employed by IBM to work on improving Linux technology these days. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 13:11:11 2002 Delivered-To: freebsd-smp@freebsd.org Received: from neptune.deep-ocean.net (APastourelles-102-1-2-208.abo.wanadoo.fr [217.128.208.208]) by hub.freebsd.org (Postfix) with ESMTP id 6BA6437B429 for ; Sun, 13 Jan 2002 13:10:36 -0800 (PST) Received: from there (scylla [192.168.0.4]) by neptune.deep-ocean.net (Postfix) with SMTP id 497085EF04 for ; Sun, 13 Jan 2002 22:10:30 +0100 (CET) From: Olivier Cortes Organization: Deep-Ocean.org To: freebsd-smp@freebsd.org Subject: usb problem / wrong irq with IO_APIC Date: Sun, 13 Jan 2002 22:10:35 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_NTAWGT3KDOZ62Z1NZQIH" Message-Id: <20020113211030.497085EF04@neptune.deep-ocean.net> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --------------Boundary-00=_NTAWGT3KDOZ62Z1NZQIH Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Hi, I ask my question here because i think my problem is SMP-related. it occurs both in STABLE and CURRENT. I've got an ASUS CUV4X-D with two PIII 800 and 1Gig RAM. various PCI cards (fxp, ahc) and GeForce2MX agp. On my USB hub (on motherboard) i use a Logitech Desktop (iTouch Keyboard and Mouse, both cordless). In the BIOS, i assigned IRQ 11 to the USB controller. With FreeBSD 4.4-STABLE in single processor mode and under 5.0-CURRENT (single proc mode too) the usb subsystem works perfectly (i can assign a keymap to the keyboard on the vtyXX, use it under Xfree, and the mouse too with all buttons... ). In SMP mode, after the IO_APIC init, the USB controller gets IRQ 2 assigned. It doesn't work at all. if i try to plug out and back in one or another device, the kernel reports a "problem with port X on usb hub Y, disabling it.". Is there a way to manually reassign the good irq to the usb controller (and make it work) ? thanks in advance for your help. I provide my SMP kernel file (GENERIC minus some drivers i don't use) and my SMP dmesg. in single proc mode, the kernel file is *exactly* the same, with the "SMP" and "IO_APIC" lines removed. best regards, -- Olivier Cortes Administrateur d'Unix libres --------------Boundary-00=_NTAWGT3KDOZ62Z1NZQIH Content-Type: text/plain; charset="iso-8859-15"; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDIgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDQuNS1QUkVSRUxFQVNFICM1OiBNb24gSmFuICA3IDE3OjUw OjAxIENFVCAyMDAyCiAgICByb290QHNjeWxsYS5kZWVwLW9jZWFuLmxvY2FsOi91c3Ivb2JqL3Vz ci9zcmMvc3lzL1NDWUxMQQpUaW1lY291bnRlciAiaTgyNTQiICBmcmVxdWVuY3kgMTE5MzE4MiBI egpDUFU6IFBlbnRpdW0gSUlJL1BlbnRpdW0gSUlJIFhlb24vQ2VsZXJvbiAoODAzLjYxLU1IeiA2 ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4Njg2ICBTdGVw cGluZyA9IDYKICBGZWF0dXJlcz0weDM4M2ZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUs TUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsTU1YLEZYU1IsU1NF PgpyZWFsIG1lbW9yeSAgPSAxMDczNzI1NDQwICgxMDQ4NTYwSyBieXRlcykKYXZhaWwgbWVtb3J5 ID0gMTA0MTE0MTc2MCAoMTAxNjc0MEsgYnl0ZXMpClByb2dyYW1taW5nIDI0IHBpbnMgaW4gSU9B UElDICMwCklPQVBJQyAjMCBpbnRwaW4gMiAtPiBpcnEgMApGcmVlQlNEL1NNUDogTXVsdGlwcm9j ZXNzb3IgbW90aGVyYm9hcmQKIGNwdTAgKEJTUCk6IGFwaWMgaWQ6ICAzLCB2ZXJzaW9uOiAweDAw MDQwMDExLCBhdCAweGZlZTAwMDAwCiBjcHUxIChBUCk6ICBhcGljIGlkOiAgMCwgdmVyc2lvbjog MHgwMDA0MDAxMSwgYXQgMHhmZWUwMDAwMAogaW8wIChBUElDKTogYXBpYyBpZDogIDIsIHZlcnNp b246IDB4MDAxNzgwMTEsIGF0IDB4ZmVjMDAwMDAKUHJlbG9hZGVkIGVsZiBrZXJuZWwgImtlcm5l bCIgYXQgMHhjMDM5YTAwMC4KUHJlbG9hZGVkIGVsZiBtb2R1bGUgInNuZF9lbXUxMGsxLmtvIiBh dCAweGMwMzlhMGE4LgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAic25kX3BjbS5rbyIgYXQgMHhjMDM5 YTE0Yy4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKbWQwOiBNYWxsb2MgZGlzawpV c2luZyAkUElSIHRhYmxlLCA3IGVudHJpZXMgYXQgMHhjMDBmMTI3MApucHgwOiA8bWF0aCBwcm9j ZXNzb3I+IG9uIG1vdGhlcmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKcGNpYjA6IDxIb3N0 IHRvIFBDSSBicmlkZ2U+IG9uIG1vdGhlcmJvYXJkCklPQVBJQyAjMCBpbnRwaW4gMTggLT4gaXJx IDIKSU9BUElDICMwIGludHBpbiAxNyAtPiBpcnEgNQpJT0FQSUMgIzAgaW50cGluIDE2IC0+IGly cSA5CklPQVBJQyAjMCBpbnRwaW4gMTkgLT4gaXJxIDEwCnBjaTA6IDxQQ0kgYnVzPiBvbiBwY2li MApwY2liMjogPFZJQSA4MkM1OThNVlAgKEFwb2xsbyBNVlAzKSBQQ0ktUENJIChBR1ApIGJyaWRn ZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMgpwY2kxOiA8 TlZpZGlhIG1vZGVsIDAxMTAgZ3JhcGhpY3MgYWNjZWxlcmF0b3I+IGF0IDAuMCBpcnEgOQppc2Fi MDogPFZJQSA4MkM2ODYgUENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSA0LjAgb24gcGNpMAppc2Ew OiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPFZJQSA4MkM2ODYgQVRBMTAwIGNvbnRyb2xs ZXI+IHBvcnQgMHhkODAwLTB4ZDgwZiBhdCBkZXZpY2UgNC4xIG9uIHBjaTAKYXRhMDogYXQgMHgx ZjAgaXJxIDE0IG9uIGF0YXBjaTAKYXRhMTogYXQgMHgxNzAgaXJxIDE1IG9uIGF0YXBjaTAKdWhj aTA6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZDQwMC0weGQ0MWYgaXJxIDIg YXQgZGV2aWNlIDQuMiBvbiBwY2kwCnVzYjA6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBv biB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBWSUEgVUhDSSByb290IGh1Yiwg Y2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kxOiA8VklBIDgzQzU3MiBVU0IgY29udHJvbGxlcj4g cG9ydCAweGQwMDAtMHhkMDFmIGlycSAyIGF0IGRldmljZSA0LjMgb24gcGNpMAp1c2IxOiA8VklB IDgzQzU3MiBVU0IgY29udHJvbGxlcj4gb24gdWhjaTEKdXNiMTogVVNCIHJldmlzaW9uIDEuMAp1 aHViMTogVklBIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx CnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApwY20wOiA8Q3Jl YXRpdmUgRU1VMTBLMT4gcG9ydCAweGI4MDAtMHhiODFmIGlycSA1IGF0IGRldmljZSAxMS4wIG9u IHBjaTAKZnhwMDogPEludGVsIFBybyAxMC8xMDBCLzEwMCsgRXRoZXJuZXQ+IHBvcnQgMHhiMDAw LTB4YjAxZiBtZW0gMHhlYzgwMDAwMC0weGVjOGZmZmZmLDB4ZWYwMDAwMDAtMHhlZjAwMGZmZiBp cnEgOSBhdCBkZXZpY2UgMTIuMCBvbiBwY2kwCmZ4cDA6IEV0aGVybmV0IGFkZHJlc3MgMDA6YTA6 Yzk6ZWE6YWI6ZmUKaW5waHkwOiA8aTgyNTU1IDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IG9uIG1p aWJ1czAKaW5waHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgYXV0bwphaGMwOiA8QWRhcHRlYyAyOTQwIFVsdHJhIFNDU0kgYWRhcHRlcj4gcG9ydCAw eGE4MDAtMHhhOGZmIG1lbSAweGVjMDAwMDAwLTB4ZWMwMDBmZmYgaXJxIDEwIGF0IGRldmljZSAx My4wIG9uIHBjaTAKYWljNzg4MDogVWx0cmEgV2lkZSBDaGFubmVsIEEsIFNDU0kgSWQ9NywgMTYv MjU1IFNDQnMKcGNpYjE6IDxIb3N0IHRvIFBDSSBicmlkZ2U+IG9uIG1vdGhlcmJvYXJkCnBjaTI6 IDxQQ0kgYnVzPiBvbiBwY2liMQpvcm0wOiA8T3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhjYzAwMC0w eGNjN2ZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQg cG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gZmxhZ3MgMHgxIGly cSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBv biBhdGtiZGMwCnBzbTA6IG1vZGVsIEludGVsbGlNb3VzZSBFeHBsb3JlciwgZGV2aWNlIElEIDQK dmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAw LTB4YmZmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24g aXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNpbzAgYXQg cG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGlzYTAKc2lvMDogdHlwZSAxNjU1 MEEKc2lvMSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYTAKc2lvMTogdHlwZSAxNjU1 MEEKcHBjMDogPFBhcmFsbGVsIHBvcnQ+IGF0IHBvcnQgMHgzNzgtMHgzN2YgaXJxIDcgb24gaXNh MApwcGMwOiBTTUMtbGlrZSBjaGlwc2V0IChFQ1AvRVBQL1BTMi9OSUJCTEUpIGluIENPTVBBVElC TEUgbW9kZQpwcGMwOiBGSUZPIHdpdGggMTYvMTYvOCBieXRlcyB0aHJlc2hvbGQKbHB0MDogPFBy aW50ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFs bGVsIEkvTz4gb24gcHBidXMwCkFQSUNfSU86IFRlc3RpbmcgODI1NCBpbnRlcnJ1cHQgZGVsaXZl cnkKQVBJQ19JTzogcm91dGluZyA4MjU0IHZpYSBJT0FQSUMgIzAgaW50cGluIDIKU01QOiBBUCBD UFUgIzEgTGF1bmNoZWQhCmFkMDogMjkzMTRNQiA8SUJNLURUTEEtMzA3MDMwPiBbNTk1NjAvMTYv NjNdIGF0IGF0YTAtbWFzdGVyIFVETUExMDAKYWNkMDogRFZELVJPTSA8TWVtb3JleCBEVkQtTUFY WDEyNDA+IGF0IGF0YTEtbWFzdGVyIHVzaW5nIFBJTzQKYWZkMDogOTZNQiA8SU9NRUdBIFpJUCAx MDAgQVRBUEk+IFszMi82NC85Nl0gYXQgYXRhMS1zbGF2ZSB1c2luZyBQSU8wCk1vdW50aW5nIHJv b3QgZnJvbSB1ZnM6L2Rldi9hZDBzMmEK --------------Boundary-00=_NTAWGT3KDOZ62Z1NZQIH Content-Type: text/plain; charset="iso-8859-15"; name="SCYLLA" Content-Transfer-Encoding: base64 Content-Description: kernel config file Content-Disposition: attachment; filename="SCYLLA" bWFjaGluZQkJaTM4NgpjcHUJCUk2ODZfQ1BVCmlkZW50CQlTQ1lMTEEKbWF4dXNlcnMJMApvcHRp b25zCQlBUElDX0lPCm9wdGlvbnMJCVNNUAoKb3B0aW9ucyAJSU5FVAkJCSNJbnRlck5FVHdvcmtp bmcKb3B0aW9ucyAJRkZTCQkJI0JlcmtlbGV5IEZhc3QgRmlsZXN5c3RlbQpvcHRpb25zIAlGRlNf Uk9PVAkJI0ZGUyB1c2FibGUgYXMgcm9vdCBkZXZpY2UgW2tlZXAgdGhpcyFdCm9wdGlvbnMgCVNP RlRVUERBVEVTCQkjRW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydApvcHRpb25zCQlVRlNf RElSSEFTSApvcHRpb25zIAlNRlMJCQkjTWVtb3J5IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJTURfUk9P VAkJCSNNRCBpcyBhIHBvdGVudGlhbCByb290IGRldmljZQpvcHRpb25zIAlORlMJCQkjTmV0d29y ayBGaWxlc3lzdGVtCm9wdGlvbnMgCU1TRE9TRlMJCQkjTVNET1MgRmlsZXN5c3RlbQpvcHRpb25z IAlDRDk2NjAJCQkjSVNPIDk2NjAgRmlsZXN5c3RlbQpvcHRpb25zIAlDRDk2NjBfUk9PVAkJI0NE LVJPTSB1c2FibGUgYXMgcm9vdCwgQ0Q5NjYwIHJlcXVpcmVkCm9wdGlvbnMgCVBST0NGUwkJCSNQ cm9jZXNzIGZpbGVzeXN0ZW0Kb3B0aW9ucyAJQ09NUEFUXzQzCQkjQ29tcGF0aWJsZSB3aXRoIEJT RCA0LjMgW0tFRVAgVEhJUyFdCm9wdGlvbnMgCVNDU0lfREVMQVk9MTAwMAkjRGVsYXkgKGluIG1z KSBiZWZvcmUgcHJvYmluZyBTQ1NJCm9wdGlvbnMgCVVDT05TT0xFCQkjQWxsb3cgdXNlcnMgdG8g Z3JhYiB0aGUgY29uc29sZQpvcHRpb25zCQlVU0VSQ09ORklHCm9wdGlvbnMgCUtUUkFDRQkJCSNr dHJhY2UoMSkgc3VwcG9ydApvcHRpb25zIAlTWVNWU0hNCQkJI1NZU1Ytc3R5bGUgc2hhcmVkIG1l bW9yeQpvcHRpb25zIAlTWVNWTVNHCQkJI1NZU1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXMKb3B0aW9u cyAJU1lTVlNFTQkJCSNTWVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJUDEwMDNfMUIJCSNQ b3NpeCBQMTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9ucwpvcHRpb25zIAlfS1BPU0lYX1BSSU9S SVRZX1NDSEVEVUxJTkcKb3B0aW9ucwkJSUNNUF9CQU5ETElNCQkjUmF0ZSBsaW1pdCBiYWQgcmVw bGllcwpvcHRpb25zIAlLQkRfSU5TVEFMTF9DREVWCSMgaW5zdGFsbCBhIENERVYgZW50cnkgaW4g L2RldgoKZGV2aWNlCQlpc2EKZGV2aWNlCQllaXNhCmRldmljZQkJcGNpCgojZGV2aWNlCQlmZGMw CWF0IGlzYT8gcG9ydCBJT19GRDEgaXJxIDYgZHJxIDIKI2RldmljZQkJZmQwCWF0IGZkYzAgZHJp dmUgMAojZGV2aWNlCQlmZDEJYXQgZmRjMCBkcml2ZSAxCiMgQVRBIGFuZCBBVEFQSSBkZXZpY2Vz CmRldmljZQkJYXRhMAlhdCBpc2E/IHBvcnQgSU9fV0QxIGlycSAxNApkZXZpY2UJCWF0YTEJYXQg aXNhPyBwb3J0IElPX1dEMiBpcnEgMTUKZGV2aWNlCQlhdGEKZGV2aWNlCQlhdGFkaXNrCQkJIyBB VEEgZGlzayBkcml2ZXMKZGV2aWNlCQlhdGFwaWNkCQkJIyBBVEFQSSBDRFJPTSBkcml2ZXMKZGV2 aWNlCQlhdGFwaWZkCQkJIyBBVEFQSSBmbG9wcHkgZHJpdmVzCmRldmljZQkJYXRhcGlzdAkJCSMg QVRBUEkgdGFwZSBkcml2ZXMKb3B0aW9ucyAJQVRBX1NUQVRJQ19JRAkJI1N0YXRpYyBkZXZpY2Ug bnVtYmVyaW5nCgojIFNDU0kgQ29udHJvbGxlcnMKZGV2aWNlCQlhaGMJCSMgQUhBMjk0MCBhbmQg b25ib2FyZCBBSUM3eHh4IGRldmljZXMKZGV2aWNlCQlzeW0JCSMgTkNSL1N5bWJpb3MgTG9naWMg KG5ld2VyIGNoaXBzZXRzKQpkZXZpY2UJCXNjYnVzCQkjIFNDU0kgYnVzIChyZXF1aXJlZCkKZGV2 aWNlCQlkYQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykKZGV2aWNlCQlzYQkJIyBTZXF1ZW50aWFs IEFjY2VzcyAodGFwZSBldGMpCmRldmljZQkJY2QJCSMgQ0QKZGV2aWNlCQlwYXNzCQkjIFBhc3N0 aHJvdWdoIGRldmljZSAoZGlyZWN0IFNDU0kgYWNjZXNzKQoKZGV2aWNlCQlhdGtiZGMwCWF0IGlz YT8gcG9ydCBJT19LQkQKZGV2aWNlCQlhdGtiZDAJYXQgYXRrYmRjPyBpcnEgMSBmbGFncyAweDEK ZGV2aWNlCQlwc20wCWF0IGF0a2JkYz8gaXJxIDEyCgpkZXZpY2UJCXZnYTAJYXQgaXNhPwoKIyBz cGxhc2ggc2NyZWVuL3NjcmVlbiBzYXZlcgpwc2V1ZG8tZGV2aWNlCXNwbGFzaAoKZGV2aWNlCQlz YzAJYXQgaXNhPyBmbGFncyAweDEwMAoKb3B0aW9ucyAgICAgICAgIFNDX1BJWEVMX01PREUgICAg ICAgICAgICMgYWRkIHN1cHBvcnQgZm9yIHRoZSByYXN0ZXIgdGV4dCBtb2RlCm9wdGlvbnMgICAg ICAgICBTQ19ERkxUX0ZPTlQgICAgICAgICAgICAjIGNvbXBpbGUgZm9udCBpbgptYWtlb3B0aW9u cyAgICAgU0NfREZMVF9GT05UPWNwODUwCm9wdGlvbnMgICAgICAgICBBVEtCRF9ERkxUX0tFWU1B UAptYWtlb3B0aW9ucyAgICAgQVRLQkRfREZMVF9LRVlNQVA9ImZyLmlzby5hY2MiCm9wdGlvbnMg ICAgICAgICBTQ19ISVNUT1JZX1NJWkU9MTAyNApvcHRpb25zICAgICAgICAgU0NfTk9STV9BVFRS PSIoRkdfQ1lBTnxCR19CTEFDSykiCm9wdGlvbnMgICAgICAgICBTQ19OT1JNX1JFVl9BVFRSPSIo RkdfQkxBQ0t8QkdfQkxVRSkiCm9wdGlvbnMgICAgICAgICBTQ19LRVJORUxfQ09OU19BVFRSPSIo RkdfTElHSFRDWUFOfEJHX0JMQUNLKSIKb3B0aW9ucyAgICAgICAgIFNDX0tFUk5FTF9DT05TX1JF Vl9BVFRSPSIoRkdfQ1lBTnxCR19CTFVFKSIKCgoKZGV2aWNlCQlucHgwCWF0IG5leHVzPyBwb3J0 IElPX05QWCBpcnEgMTMKZGV2aWNlCQlzbWJ1cwpkZXZpY2UJCXNtYgpkZXZpY2UJCWludHBtCmRl dmljZQkJaWljYnVzCmRldmljZQkJaWljc21iCgojZGV2aWNlCQlhcG0wICAgIGF0IG5leHVzPyBk aXNhYmxlIGZsYWdzIDB4MjAgIyBBZHZhbmNlZCBQb3dlciBNYW5hZ2VtZW50CmRldmljZQkJc2lv MAlhdCBpc2E/IHBvcnQgSU9fQ09NMSBmbGFncyAweDEwIGlycSA0CmRldmljZQkJc2lvMQlhdCBp c2E/IHBvcnQgSU9fQ09NMiBpcnEgMwpkZXZpY2UJCXBwYzAJYXQgaXNhPyBpcnEgNwpkZXZpY2UJ CXBwYnVzCQkjIFBhcmFsbGVsIHBvcnQgYnVzIChyZXF1aXJlZCkKZGV2aWNlCQlscHQJCSMgUHJp bnRlcgpkZXZpY2UgICAgICAgICAgcHBpICAgICAgICAgICAgICMgUGFyYWxsZWwgcG9ydCBpbnRl cmZhY2UgZGV2aWNlCgojIFBDSSBFdGhlcm5ldCBOSUNzLgpkZXZpY2UJCW1paWJ1cwkJIyBNSUkg YnVzIHN1cHBvcnQKZGV2aWNlCQlkYwkJIyBERUMvSW50ZWwgMjExNDMgYW5kIHZhcmlvdXMgd29y a2FsaWtlcwpkZXZpY2UJCWZ4cAkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3 LCA4MjU1OCkKZGV2aWNlCQl4bAkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xv bmUnJykKCnBzZXVkby1kZXZpY2UJbG9vcAkJIyBOZXR3b3JrIGxvb3BiYWNrCnBzZXVkby1kZXZp Y2UJZXRoZXIJCSMgRXRoZXJuZXQgc3VwcG9ydApwc2V1ZG8tZGV2aWNlCXBwcAkxCSMgS2VybmVs IFBQUApwc2V1ZG8tZGV2aWNlCXR1bgkxCSMgUGFja2V0IHR1bm5lbC4KcHNldWRvLWRldmljZQlw dHkJCSMgUHNldWRvLXR0eXMgKHRlbG5ldCBldGMpCnBzZXVkby1kZXZpY2UJbWQJCSMgTWVtb3J5 ICJkaXNrcyIKcHNldWRvLWRldmljZQlicGYJCSNCZXJrZWxleSBwYWNrZXQgZmlsdGVyCgojIFVT QiBzdXBwb3J0CmRldmljZQkJdWhjaQkJIyBVSENJIFBDSS0+VVNCIGludGVyZmFjZQpkZXZpY2UJ CW9oY2kJCSMgT0hDSSBQQ0ktPlVTQiBpbnRlcmZhY2UKZGV2aWNlCQl1c2IJCSMgVVNCIEJ1cyAo cmVxdWlyZWQpCmRldmljZQkJdWdlbgkJIyBHZW5lcmljCmRldmljZQkJdWhpZAkJIyAiSHVtYW4g SW50ZXJmYWNlIERldmljZXMiCmRldmljZQkJdWtiZAkJIyBLZXlib2FyZApkZXZpY2UJCXVscHQJ CSMgUHJpbnRlcgpkZXZpY2UJCXVtYXNzCQkjIERpc2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVz IHNjYnVzIGFuZCBkYQpkZXZpY2UJCXVtcwkJIyBNb3VzZQpkZXZpY2UJCXVzY2FubmVyCSMgU2Nh bm5lcnMKIyBVU0IgRXRoZXJuZXQsIHJlcXVpcmVzIG1paQpkZXZpY2UJCWF1ZQkJIyBBRE10ZWsg VVNCIGV0aGVybmV0CmRldmljZQkJY3VlCQkjIENBVEMgVVNCIGV0aGVybmV0CmRldmljZQkJa3Vl CQkjIEthd2FzYWtpIExTSSBVU0IgZXRoZXJuZXQK --------------Boundary-00=_NTAWGT3KDOZ62Z1NZQIH-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 13:14:55 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 8EFCB37B416; Sun, 13 Jan 2002 13:14:52 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 61C7A10DDFB; Sun, 13 Jan 2002 13:14:52 -0800 (PST) Date: Sun, 13 Jan 2002 13:14:52 -0800 From: Alfred Perlstein To: Terry Lambert Cc: smp@freebsd.org, jhb@freebsd.org, dillon@freebsd.org Subject: Re: making malloc(9) smp safe? Message-ID: <20020113131452.T7984@elvis.mu.org> References: <20020113050836.Q7984@elvis.mu.org> <3C41F153.DCA0A4F3@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C41F153.DCA0A4F3@mindspring.com>; from tlambert2@mindspring.com on Sun, Jan 13, 2002 at 12:42:59PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Terry Lambert [020113 12:49] wrote: > Alfred Perlstein wrote: > > Malloc has its own mutex, however when it needs to do page allocations > > via kmem_malloc() it drops the mutex and calls it. > > > > kmem_malloc() needs giant. > > > > what do I do? > > > > Do I grab giant before calling malloc(9)? > > Do I make malloc(9) aquire or recurse on giant automatically? > > (basically grab giant around kmem_malloc() call in malloc(9)) > > > > ? > > > The way Dynix does this (see UNIX Internals: The New Frontiers, > Uresh Vahalia, Chapter 12 Kernel Memory Allocation, 12.9 A > Hierarchical Allocator for Multiprocessors) is to seperate the > memory into a global pool, and per CPU pools, with a seperate > Coelesce-to-Page layer. I know dammit, I wanted a quick fix for malloc! here: http://www.freebsd.org/~alfred/memcache :P -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 13:18:16 2002 Delivered-To: freebsd-smp@freebsd.org Received: from ns.waishi.jp (ns.waishi.jp [61.199.233.194]) by hub.freebsd.org (Postfix) with ESMTP id 78E4637B405 for ; Sun, 13 Jan 2002 13:18:09 -0800 (PST) Received: from ns.waishi.jp (ns.waishi.jp [61.199.233.194]) by ns.waishi.jp (Postfix) with SMTP id 3B9C9231A3 for ; Mon, 14 Jan 2002 06:18:06 +0900 (JST) Date: Mon, 14 Jan 2002 06:18:06 +0900 From: Shin-ichi YOSHIMOTO To: freebsd-smp@FreeBSD.org Subject: AE_NOT_FOUND and Broken MP table Message-Id: <20020114061806.15b28416.yosimoto@waishi.jp> Organization: WAISHI.JP X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, all. I'm using a SuperMicro P3TDE6 dual Pentium III motherbord in current. I have two questions (problems ?). (1) ACPI: table load failed: AE_NOT_FOUND (2) Broken MP table detected: 8254 is not connected to IOAPIC #0 Is this OK ? dmesg is following: > dmesg Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sun Jan 13 07:11:07 JST 2002 yosimoto@daemon.waishi.jp:/usr/obj/usr/src/sys/DAEMON Preloaded elf kernel "/boot/kernel/kernel" at 0xc03aa000. Preloaded elf module "/boot/kernel/snd_es137x.ko" at 0xc03aa0a8. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc03aa158. Preloaded elf module "/boot/kernel/agp.ko" at 0xc03aa204. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc03aa2ac. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1266.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 1073676288 (1048512K bytes) avail memory = 1040822272 (1016428K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec00000 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Pentium Pro MTRR support enabled Using $PIR table, 10 entries at 0xc00f52e0 ACPI-0204: *** Error: AcpiLoadTables: Could not load namespace: AE_NOT_FOUND ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NOT_FOUND ACPI: table load failed: AE_NOT_FOUND [snip] sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 -- Shin-ichi YOSHIMOTO http://www.waishi.jp/~yosimoto/diary/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 16: 4:46 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id ABDFD37B404; Sun, 13 Jan 2002 16:04:43 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 9B7A110DDFB; Sun, 13 Jan 2002 16:04:42 -0800 (PST) Date: Sun, 13 Jan 2002 16:04:42 -0800 From: Alfred Perlstein To: jhb@freebsd.org Cc: smp@freebsd.org Subject: witness speedups? Message-ID: <20020113160442.U7984@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is there anything you can do to speed up witness a bit? Can't you add some table structures for things like find_instance() to reduce the overhead of witness? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 16:13: 8 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 864AA37B416; Sun, 13 Jan 2002 16:13:03 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA18754; Mon, 14 Jan 2002 11:12:57 +1100 Date: Mon, 14 Jan 2002 11:13:47 +1100 (EST) From: Bruce Evans X-X-Sender: To: Alfred Perlstein Cc: John Baldwin , , , Subject: Re: fd locking. In-Reply-To: <20020113052807.R7984@elvis.mu.org> Message-ID: <20020114110256.Q3471-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 13 Jan 2002, Alfred Perlstein wrote: > * Alfred Perlstein [020113 04:10] wrote: > > * Alfred Perlstein [020112 19:17] wrote: > > > * John Baldwin [020112 19:00] wrote: > > > > > > Bruce is going to not like you for adding nested includes of sys/lock.h and > > > > sys/mutex.h. Instead, add nested includes of sys/_lock.h and sys/_mutex.h, and > > > > then add sys/lock.h and sys/mutex.h to the files that need them. > > > > > > Can this be delayed? No. > > > > I'll start on this. > > Ugh, what a pain! > > Basically I wind up with an annoying problem. I want fhold and fhold_locked > to be inlines. However they use mutexes, _however_, they aren't used for > the most part, __however__ a lot of people include these files... This shows that they shouldn't be inlines, at least in the bloated case where the mutex functions are used. Don't add includes of all over to "fix" this. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 16:31: 4 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 332DF37B402; Sun, 13 Jan 2002 16:30:59 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 0A71310DDFB; Sun, 13 Jan 2002 16:30:59 -0800 (PST) Date: Sun, 13 Jan 2002 16:30:59 -0800 From: Alfred Perlstein To: Bruce Evans Cc: John Baldwin , smp@FreeBSD.ORG, dillon@FreeBSD.ORG, tanimura@FreeBSD.ORG Subject: Re: fd locking. Message-ID: <20020113163059.V7984@elvis.mu.org> References: <20020113052807.R7984@elvis.mu.org> <20020114110256.Q3471-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020114110256.Q3471-100000@gamplex.bde.org>; from bde@zeta.org.au on Mon, Jan 14, 2002 at 11:13:47AM +1100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bruce Evans [020113 16:13] wrote: > On Sun, 13 Jan 2002, Alfred Perlstein wrote: > > > * Alfred Perlstein [020113 04:10] wrote: > > > * Alfred Perlstein [020112 19:17] wrote: > > > > * John Baldwin [020112 19:00] wrote: > > > > > > > > Bruce is going to not like you for adding nested includes of sys/lock.h and > > > > > sys/mutex.h. Instead, add nested includes of sys/_lock.h and sys/_mutex.h, and > > > > > then add sys/lock.h and sys/mutex.h to the files that need them. > > > > > > > > Can this be delayed? > > No. Heh, I didn't mean for more than a couple of hours. I think I already cleaned it up. > > > > > > I'll start on this. > > > > Ugh, what a pain! > > > > Basically I wind up with an annoying problem. I want fhold and fhold_locked > > to be inlines. However they use mutexes, _however_, they aren't used for > > the most part, __however__ a lot of people include these files... > > This shows that they shouldn't be inlines, at least in the bloated case > where the mutex functions are used. Don't add includes of > all over to "fix" this. This is all taken care of now, let me know if it's ok. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 18:40:55 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id E119237B416; Sun, 13 Jan 2002 18:40:53 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020114024053.VIYC3578.rwcrmhc52.attbi.com@peter3.wemm.org>; Mon, 14 Jan 2002 02:40:53 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0E2ers77748; Sun, 13 Jan 2002 18:40:53 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 3D7763A03; Sun, 13 Jan 2002 18:40:53 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Alfred Perlstein Cc: jhb@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: witness speedups? In-Reply-To: <20020113160442.U7984@elvis.mu.org> Date: Sun, 13 Jan 2002 18:40:53 -0800 From: Peter Wemm Message-Id: <20020114024053.3D7763A03@overcee.wemm.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alfred Perlstein wrote: > Is there anything you can do to speed up witness a bit? I seem to recall something about the 'WITNESS_SKIPSPIN' option which leaves spinlocks out of the picture and speeds things up a lot. I think I have not used it before though so I dont know for sure. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Jan 13 18:41:55 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 2F31737B404; Sun, 13 Jan 2002 18:41:52 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 0911410DDFB; Sun, 13 Jan 2002 18:41:52 -0800 (PST) Date: Sun, 13 Jan 2002 18:41:52 -0800 From: Alfred Perlstein To: Peter Wemm Cc: jhb@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: witness speedups? Message-ID: <20020113184151.C7984@elvis.mu.org> References: <20020113160442.U7984@elvis.mu.org> <20020114024053.3D7763A03@overcee.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020114024053.3D7763A03@overcee.wemm.org>; from peter@wemm.org on Sun, Jan 13, 2002 at 06:40:53PM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Peter Wemm [020113 18:40] wrote: > Alfred Perlstein wrote: > > Is there anything you can do to speed up witness a bit? > > I seem to recall something about the 'WITNESS_SKIPSPIN' option which leaves > spinlocks out of the picture and speeds things up a lot. I think I have > not used it before though so I dont know for sure. Yeah, it works... ...about as good as putting high test in a saturn. :P -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jan 14 2: 3:57 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id AA9C837B421 for ; Mon, 14 Jan 2002 02:03:45 -0800 (PST) Received: (qmail 27840 invoked from network); 14 Jan 2002 10:03:44 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 10:03:44 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020113160442.U7984@elvis.mu.org> Date: Mon, 14 Jan 2002 02:03:05 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: RE: witness speedups? Cc: smp@freebsd.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 14-Jan-02 Alfred Perlstein wrote: > Is there anything you can do to speed up witness a bit? > > Can't you add some table structures for things like find_instance() > to reduce the overhead of witness? You can use WITNESS_SKIPSPIN to turn off checking on spinlocks which should help a bit since they are acquried fairly often. What table structures do you mean for find_instance()? find_instance() is basically searching a per-thread linked-list of held locks (well, not a true linked-list since it uses buckets to try and save on memory). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "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 From owner-freebsd-smp Mon Jan 14 2:10:19 2002 Delivered-To: freebsd-smp@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 0129837B41F; Mon, 14 Jan 2002 02:10:16 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id D84B610DE00; Mon, 14 Jan 2002 02:10:15 -0800 (PST) Date: Mon, 14 Jan 2002 02:10:15 -0800 From: Alfred Perlstein To: John Baldwin Cc: smp@freebsd.org Subject: Re: witness speedups? Message-ID: <20020114021015.B26067@elvis.mu.org> References: <20020113160442.U7984@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Mon, Jan 14, 2002 at 02:03:05AM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * John Baldwin [020114 02:03] wrote: > > On 14-Jan-02 Alfred Perlstein wrote: > > Is there anything you can do to speed up witness a bit? > > > > Can't you add some table structures for things like find_instance() > > to reduce the overhead of witness? > > You can use WITNESS_SKIPSPIN to turn off checking on spinlocks which should > help a bit since they are acquried fairly often. What table structures do you > mean for find_instance()? find_instance() is basically searching a per-thread > linked-list of held locks (well, not a true linked-list since it uses buckets > to try and save on memory). Oh, I thought it was traversing a global list. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Jan 14 14:49:29 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by hub.freebsd.org (Postfix) with ESMTP id 2E77937B405 for ; Mon, 14 Jan 2002 14:49:12 -0800 (PST) Received: from pc1-stme2-0-cust102.cdf.cable.ntl.com ([62.252.56.102]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020114224911.LPVY8848.mta02-svc.ntlworld.com@pc1-stme2-0-cust102.cdf.cable.ntl.com> for ; Mon, 14 Jan 2002 22:49:11 +0000 Received: from lfarr (l-farr.bka.epcdirect.co.uk [192.168.10.200]) by pc1-stme2-0-cust102.cdf.cable.ntl.com (8.11.6/8.11.6) with ESMTP id g0EMn9K25986 for ; Mon, 14 Jan 2002 22:49:10 GMT (envelope-from freebsd-smp@epcdirect.co.uk) From: "Lawrence Farr" To: Subject: Sorry if this is a dumb question! Date: Mon, 14 Jan 2002 22:49:09 -0000 Message-ID: <000701c19d4d$af64dc70$c80aa8c0@lfarr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a Dell Poweredge 6400, Quad Xeon 700/2Mb cache with 4Gb memory. Ran STABLE on it cvsupped and built today, and with a make -j8 buildworld, managed to get it to use all 4 processors pretty much flat out. I then CVSupped to CURRENT, built and installes world and GENERIC. I then built an SMP enabled kernel, installed and tried again. Make -j8 gives 75% free processor in top, and even running a couple of different makes shows at most 74% free, so I guess only one CPU is running. Also, if shell access is of any use to any developers on this box, please let me know! Lawrence Farr EPC Direct Limited Heres the dmesg: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Mon Jan 14 21:04:11 GMT 2002 root@benny.epcdirect.co.uk:/usr/obj/usr/src/sys/QuadXeon Preloaded elf kernel "/boot/kernel/kernel" at 0xc0499000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04990a8. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (699.29-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6a1 Stepping = 1 Features=0x383fbff real memory = 4160741376 (4063224K bytes) avail memory = 4054220800 (3959200K bytes) Changing APIC ID for IO APIC #0 from 0 to 4 on chip Changing APIC ID for IO APIC #1 from 0 to 5 on chip Programming 16 pins in IOAPIC #0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 3, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu2 (AP): apic id: 2, version: 0x00040011, at 0xfee00000 cpu3 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec00000 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Pentium Pro MTRR support enabled Using $PIR table, 11 entries at 0xc00fc350 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_cpu2: on acpi0 acpi_cpu3: on acpi0 acpi_pcib0: on acpi0 IOAPIC #1 intpin 1 -> irq 2 IOAPIC #1 intpin 2 -> irq 10 IOAPIC #1 intpin 5 -> irq 11 pci0: on acpi_pcib0 pci0: at device 4.0 (no driver attached) ahc0: port 0xe800-0xe8ff mem 0xfbefe000-0xfbefefff irq 2 at device 5.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0xe400-0xe4ff mem 0xfbefd000-0xfbefdfff irq 10 at device 5.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs pci0: at device 7.0 (no driver attached) isab0: port 0x8a0-0x8af at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x8b0-0x8bf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xfbefb000-0xfbefbfff irq 5 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (unknown) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered acpi_pcib1: on acpi0 IOAPIC #1 intpin 7 -> irq 13 IOAPIC #1 intpin 8 -> irq 16 pci3: on acpi_pcib1 ti0: <3Com 3c985-SX Gigabit Ethernet> mem 0xfacfc000-0xfacfffff irq 13 at device 9.0 on pci3 ti0: Ethernet address: 00:60:08:f5:c9:23 dc0: port 0xcc80-0xccff mem 0xfacfbc00-0xfacfbfff irq 16 at device 10.0 on pci3 dc0: Ethernet address: 00:c0:f0:4d:03:6d miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto acpi_pcib2: on acpi0 pci12: on acpi_pcib2 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold fdc: fdc0 already exists; skipping it ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0: