From owner-freebsd-smp Sat Aug 21 20:36:28 1999 Delivered-To: freebsd-smp@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 5767414EE9 for ; Sat, 21 Aug 1999 20:36:24 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id XAA09443; Sat, 21 Aug 1999 23:34:45 -0400 (EDT) (envelope-from luoqi) Date: Sat, 21 Aug 1999 23:34:45 -0400 (EDT) From: Luoqi Chen Message-Id: <199908220334.XAA09443@lor.watermarkgroup.com> To: blanquer@cs.ucsb.edu, luoqi@watermarkgroup.com Subject: Re: SMP differences between -stable and -current (RE: wine and SMP) Cc: freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Do you have any docs explaining this? I mean the way you are > implementing it...The docs I've seen are usually explaining possible > strategies and problems, but it's difficult to know the actual status of > it. Of course one can always take a look to the kernel code, but it's > not easy task, specially because the SMP code it's kinda sparse... Unfortunately I don't have any docs. But I can explain briefly what I have done. To move interrupt handler out of GKL, we have to rely on spin locks for critical region protection. The problem with spin locks is that they are often nested and could be in any order, potential deadlock hazards. The solution is to acquire GKL when we need to raise cpl the 2nd time (the first time is when the interrupt handler is entered), this is not always possible and interrupt handler can't wait. If we can't get GKL to come to us, we go to GKL: we suspend the interrupt handler and forward it to the GKL holder via an IPI, and the lock holder would complete the rest. This effectively pushs GKL down to the boundary of spl calls (so I didn't move interrupt handlers completely outside the GKL, but most of them), this is probably the furthest we could go without the introduction of finer grained subsystem locks. > With some docs about the actual implementation would be much more easy > for others to start playing with things like proc. affinity and many other > performance improvements... > > BTW is that code going to be part of -current? if so, do you know when > (aprox)? > I hope so. Timewise, I don't know. I have just successfully finished a make world after closing down one last race window today, so at least the idea works. But the code is a mess, I need to clean it up, probably rework some part, and deal with cases I currently ignored. > Nice, that should really make a difference in for example server boxes > with a lot of traffic... > It didn't improvement the make world time, but that's no surprise, interrupts account for less than 1% of cpu usage. It should help, e.g., a web server, with simultaneous disk and network activities, but I don't have a test environment. > Josep M. > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message