From owner-freebsd-current Mon Dec 21 09:31:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23634 for freebsd-current-outgoing; Mon, 21 Dec 1998 09:31:55 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles130.castles.com [208.214.165.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA23629 for ; Mon, 21 Dec 1998 09:31:53 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id JAA02261; Mon, 21 Dec 1998 09:29:09 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812211729.JAA02261@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Chuck Robey cc: Mike Smith , "Daniel C. Sobral" , current@FreeBSD.ORG Subject: Re: Pb with COMPAT_LINUX_THREADS In-reply-to: Your message of "Mon, 21 Dec 1998 11:30:25 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Dec 1998 09:29:09 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I have been wondering about this... Multithreading is usually used to improve > > > performance. Wouldn't this "on-demand" allocation of shared signals impact of > > > performance? > > > > You typically thread for the concurrency win, and wear the startup cost > > as an overhead that you have to pay back with concurrency. Given that > > at the moment we're looking at a heavyweight thread implementation, > > this extra allocation is relatively trivial in the scheme of things. > > My semester is over, I'm only now starting to catch up on the > interesting stuff on threads ... for scheduling purposes, then, you want > to keep track of how many active threads a threaded process has, and > have the scheduler grab that many cpus when a context switch occurs? No. You want to schedule each individual thread as though it were a process in and of itself. > How is the time for the threaded process to be accounted? I see (for > purposes of scheduler priorities) that either total cputime given, > across all cpus, could be used, if you wanted to keep non-threaded apps > on an even parity with threaded apps. Alternatively, if you wanted to > give threaded apps a definite win, then you would only keep cpu stats, > perhaps, on a parent thread? In the current LinuxThreads support mode, threads are processes, so each thread's time is accounted against itself. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message