Date: Sat, 28 Apr 2001 09:28:31 +0800 From: "David Xu" <bsddiy@163.net> To: "Matt Dillon" <dillon@earth.backplane.com>, "Nate Williams" <nate@yogotech.com> Cc: "David O'Brien" <obrien@FreeBSD.ORG>, "Julian Elischer" <julian@elischer.org>, <Arch@FreeBSD.ORG>, "Daniel Eischen" <eischen@vigrid.com> Subject: Re: KSE threading support (first parts) Message-ID: <001e01c0cf82$ac300460$cc01a8c0@xyf> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: Matt Dillon <dillon@earth.backplane.com> To: Nate Williams <nate@yogotech.com> Cc: David O'Brien <obrien@FreeBSD.ORG>; Julian Elischer <julian@elischer.org>; <Arch@FreeBSD.ORG>; Daniel Eischen <eischen@vigrid.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001e01c0cf82$ac300460$cc01a8c0>