From owner-freebsd-stable Sun Dec 10 15: 3:14 2000 From owner-freebsd-stable@FreeBSD.ORG Sun Dec 10 15:03:12 2000 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from shell.webmaster.com (unknown [216.152.64.152]) by hub.freebsd.org (Postfix) with ESMTP id 9D3CA37B400 for ; Sun, 10 Dec 2000 15:03:12 -0800 (PST) Received: from whenever ([216.152.68.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Sun, 10 Dec 2000 15:02:05 -0800 From: "David Schwartz" To: "Michael Bacarella" Cc: "Noor Dawod" , Subject: RE: MySQLd not using both CPUs Date: Sun, 10 Dec 2000 15:03:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <20001210112921.A5531@mmap.nyct.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry to continue this thread, but I think this last point is of sufficient general interest. I'll shut up now. ;) > On Sun, Dec 10, 2000 at 12:54:01AM -0800, David Schwartz wrote: > I think the whole 1 thread to 1 process scheme that LinuxThreads > uses would > be much slower under FreeBSD. Unless some magic has been put in > to special case this scheme in the scheduler... you'll probably see > better performance running LinuxThreads with Linux. > > -- > Michael Bacarella This is why I say that LinuxThreads is better for _good_ code and libc_r is better for _poor_ code. Good code does not create more running threads than there are processes to run them on. Bad code creates tons of senseless threads, which libc_r schedules just fine and the kernel does not. If you create a thread to keep a CPU busy, then there should be a CPU to run that thread on. If you create a thread to pend a disk I/O operation, then that thread should be blocked waiting for the I/O to complete. So long as you only create threads for a legitimate reason, you will not cripple the scheduler. If you assume 2 CPUs and perhaps one can usefully pend 6 I/O operations, you're talking about 8 threads. Add another few threads so you can have one to wait for signals, one to fire timers, one to talk to a library that might not be thread safe, and you have perhaps 12 threads. If that hurts FreeBSD's scheduler, then FreeBSD is badly broken. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message