From owner-freebsd-arch Fri Apr 27 18:28: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 777DC37B422; Fri, 27 Apr 2001 18:28:01 -0700 (PDT) (envelope-from bsddiy@163.net) Received: from xyf ([192.168.1.204]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id JAA02080; Sat, 28 Apr 2001 09:24:43 +0800 Message-ID: <001e01c0cf82$ac300460$cc01a8c0@xyf> From: "David Xu" To: "Matt Dillon" , "Nate Williams" Cc: "David O'Brien" , "Julian Elischer" , , "Daniel Eischen" References: <3AE71067.FF4BD029@elischer.org><20010425110940.L1790@fw.wintelcom.net><3AE85776.92D6BD90@elischer.org><20010426120630.A92915@dragon.nuxi.com><200104270015.f3R0FAi62512@earth.backplane.com><15081.39397.944224.776391@nomad.yogotech.com><200104271701.f3RH1Tk05185@earth.backplane.com> <15081.42735.860662.876478@nomad.yogotech.com> <200104271717.f3RHHGp05457@earth.backplane.com> Subject: Re: KSE threading support (first parts) Date: Sat, 28 Apr 2001 09:28:31 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Original Message ----- From: Matt Dillon To: Nate Williams Cc: David O'Brien ; Julian Elischer ; ; Daniel Eischen Sent: Saturday, April 28, 2001 1:17 AM Subject: Re: KSE threading support (first parts) > > You seem to believe that not being able to run KSE's for the same > process concurrently somehow kills the whole concept of SMP. > > Well, that's complete bullshit. KSE's are extremely short-running > affairs in kernel mode, especially when you consider the most likely > asynchronizing case (a simple blocking situation that will most commonly > be in a read() or write()). Serializing them within the context of a > single process will actually *IMPROVE* SMP performance, not make it worse. No, most multi-threaded programs use threads to improve concurrent I/O, think about MySQL, why our version is slower than their Linux version? because we serialize read()/write() in a multi-threaded program, this is our failure. > Running multiple kernel contexts for the same process on different > cpu's concurrently means that you must now lock every single aspect > of the 'current process' concept, and cannot make any assumptions > whatsoever in regards to accessing elements of the current process. > Well, that's just plain insane. You will wind up with so many fragging > locks and mutexes in the kernel that what performance gain you might > have thought you could get is now completely blown away by the locking > overhead. > Yes, it must be done! I believe FreeBSD-current already make proc structure and many other resources to support concurrent access. I don't think there will have many new lock-down should be made. a KSE is a scheduler unit, just like a proc in running queue, I don't see there are so many different on this concept. > This is another aspect of the problem you run into when you start > trying to preempt a process running in the kernel arbitrarily. Suddenly > all the assumptions you were able to make before that resulted in > optimal code paths now must be thrown out the window and replaced with > a godaweful number of locks to protect kernel contexts from unexpected > interruptions. That's insane as well. You are introducing a 'solution' > to a problem that doesn't exist and breaking any chance we have of > getting a reliable kernel in anything less then a few years in the process. > > If we were writing a kernel completely from scratch we could probably > construct it to allow these things, but trying to do it with the current > base is impossible -- you will never get something reliable or efficient > at the end of this road. Or perhaps I should phrase it: The only way > you will get anything close to reliable will be to effectively revert > the system to the days of the single giant lock, because you will need > so many fraggin locks to deal with the consequences you might as well > have a single big giant lock. > > -Matt a well designed multi-thread program can cleanly dispatch its internal tasks to different threads, it will avoid collision on its internal resources. BGL is a joke and bogus for SMP, don't talk about it. Regards, David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message