Date: Tue, 16 Mar 1999 12:11:34 -0700 From: Brett Glass <brett@lariat.org> To: Terry Lambert <tlambert@primenet.com>, sas@schell.de (Sascha Schumann) Cc: freebsd-chat@FreeBSD.ORG Subject: Re: FreeBSD 3.1 SMP outperforms SuSE 6.0 SMP by factor 2.3 !!! Message-ID: <4.1.19990316120025.03f3e4a0@localhost> In-Reply-To: <199903161839.LAA09895@usr06.primenet.com> References: <19990316150715.A3316@schell.de>
next in thread | previous in thread | raw e-mail | index | archive | help
At 06:39 PM 3/16/99 +0000, Terry Lambert wrote: >The main SMP competitive failur for FreeBSD and Linux is the lack >of a unified central architectural plan, with a roadmap going >forward that addresses the SMP issue, in toto. Agreed. BeOS is actually the best in this regard -- far better than NT. It does very well at allocating resources and processing power while maintaining reasonable response times. Personally, I've always been an advocate of AMP (asymmetrical multiprocessing). I see no reason to believe that sauce for the goose is sauce for the gander, or that (given that current CPU architectures are not designed for efficient context switching) it truly pays to toss processes around between CPUs like a football. I'd rather see one or more processors devoted exclusively to real-time tasks and I/O (kernel-level stuff) while others handle tasks in which less determinism is required (userland stuff). The two classes of processors could run different styles of kernels for optimal performance. Yes, there could be multiple processors in each class; it might be especially helpful, in particular, if multiple CPUs could handle unrelated userland tasks. But these could be coupled more loosely, because they wouldn't have to deal with low-level system management tasks. Hence, they wouldn't butt heads as often as they do in current SMP architectures. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.1.19990316120025.03f3e4a0>