Date: Fri, 16 Mar 2001 19:10:46 +0200 From: Peter Pentchev <roam@orbitel.bg> To: David Xu <bsddiy@21cn.com> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: status of KSE? Message-ID: <20010316191046.B428@ringworld.oblivion.bg> In-Reply-To: <3715226734.20010316125924@21cn.com>; from bsddiy@21cn.com on Fri, Mar 16, 2001 at 12:59:24PM %2B0800 References: <424452460.20010315150427@21cn.com> <3AB19407.222CAC7C@elischer.org> <3715226734.20010316125924@21cn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 16, 2001 at 12:59:24PM +0800, David Xu wrote: > Hello Julian, > > Friday, March 16, 2001, 12:18:15 PM, you wrote: > > JE> David Xu wrote: > >> > >> I wonder status of KSE, I am dreaming rewrite our application > >> server using kqueue+pthread(KSE), current, we use poll()+pthread > >> because pthread does not work with kqueue at present. > >> > >> -- > >> Best regards, > >> David Xu > > JE> KSE is not into coding yet. > JE> we have a basic design and have soem documents but > JE> have been waiting for the SMPng stuff to settle a bit before we > JE> hit the kernel with a second huge change. > > JE> It will not be ready for a long time. do not assume that it > JE> will be ready for when you need it becasue it will not. > > I know KSE is not related to SMP and will run on UP. my primary > idea is want to run parellel I/O task in same process with pthread, > simply because FreeBSD pthread does not allow me to do multipile > I/O tasks at same time on disk file, of course, it is also conflicted > with SYSV IPC, so I think of KSE. I don't care about SMP, CPU is > enough fast now, I have already seen 1.3G hz CPU, how fast! I think > Intel and AMD can very easy to double their CPU clock, hope I can see > 3Ghz CPU in next year. I really do think KSE should work before SMP, > but it is obvious not. think about Apache 2.0, it is already > multi-threaded, FreeBSD pthread will be blocked at disk I/O, it is very > bad for Apache 2.0 . I believe Julian's SMP-related comments were referring to the fact that SMP development has rendered the -current kernel somewhat unstable at times (to say the least). KSE-related work would introduce yet another probable path for instabilities, and the developers prefer dealing with one huge monster at a time. There is also the fact that KSE work shall most probably touch many places in the kernel that SMP development also touches - yet another reason to postpone KSE until SMP is kind-of done. G'luck, Peter -- You have, of course, just begun reading the sentence that you have just finished reading. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010316191046.B428>