From owner-freebsd-current Mon Dec 21 08:31:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14785 for freebsd-current-outgoing; Mon, 21 Dec 1998 08:31:55 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA14780 for ; Mon, 21 Dec 1998 08:31:51 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.1/8.8.5) with ESMTP id LAA01708; Mon, 21 Dec 1998 11:30:25 -0500 (EST) Date: Mon, 21 Dec 1998 11:30:25 -0500 (EST) From: Chuck Robey To: Mike Smith cc: "Daniel C. Sobral" , current@FreeBSD.ORG Subject: Re: Pb with COMPAT_LINUX_THREADS In-Reply-To: <199812211040.CAA00481@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 21 Dec 1998, Mike Smith wrote: > > At Mon, 21 Dec 1998 01:13:24 -0800, you wrote > > > > > >> The ifdef'd version is to let people look at it and think about it.. > > >> possibly as has been suggested, the malloc'd space might only be used if > > >> there is a sharing of signals. Otherwise it might remain in the U area. > > > > > >That's certainly one way of doing it. You could implement structure > > >compression by COW off the parent's copy of the struct instead, that'd > > >be even more efficient. > > > > 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? 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? This topic seems to be going on in two lists concurrently (FreeBSD-smp). I'd think it belongs better in smp, right? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message