From owner-freebsd-threads@FreeBSD.ORG Wed Apr 16 12:03:23 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A82F37B401; Wed, 16 Apr 2003 12:03:23 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12B1D43FAF; Wed, 16 Apr 2003 12:03:22 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <2003041619032105100hshlse>; Wed, 16 Apr 2003 19:03:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA44581; Wed, 16 Apr 2003 12:03:20 -0700 (PDT) Date: Wed, 16 Apr 2003 12:03:18 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: <20030416144217.K76635-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@freebsd.org cc: jeff@freebsd.org cc: John Polstra cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: May I add pthread_[gs]etconcurrency to the threads libraries? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 19:03:23 -0000 On Wed, 16 Apr 2003, Jeff Roberson wrote: > > On Wed, 16 Apr 2003, Daniel Eischen wrote: > > > On Wed, 16 Apr 2003, Jeff Roberson wrote: > > > On Wed, 16 Apr 2003, Daniel Eischen wrote: > > > > > > > On Wed, 16 Apr 2003, John Polstra wrote: > > > > > > > > > Hi Guys, > > > > > > > > > > Sergey Osokin sent me patches to add the standard > > > > > pthread_[gs]etconcurrency functions to our various threads > > > > > libraries. I reviewed them and they're OK. The functions don't do > > > > > anything significant, but they fill the need for this part of the > > > > > API. > > > > > > > > > > OK if I commit them this weekend? The changes don't change anything > > > > > else. They just add stuff. > > > > > > > > I'm about to implement them for real in libpthread. I'd appreciate > > > > you not adding them to that. I've got a slew of other changes that > > > > I want add to it very soon. > > > > > > > > They don't seem to make sense for libthr and libc_r unless it > > > > returns ENOTSUP. libthr is 1:1, so it is meaning less there > > > > as well as libc_r. > > > > > > It is not meaningless. Please go ahead and implement stubs if you like. > > > I intended to implement a thr_setconcurrency that these can eventually > > > use. I was just going to implement it as a simple counter on the proc > > > instead of using a full blown KSE structure just for this. > > > > > > 1:1 means one kernel thread for each user thread. It doesn't say anything > > > about how many of those threads may run at a given time. It also doesn't > > > force any scheduling scope or scheduling algorithm. > > > > OK, I was under the impression that libthr would always schedule > > threads (KSEs) to as many processors as possible. It'd be neat > > to eventually softly bind them (KSE's in general) too :-) > > > > -- > > Dan Eischen > > > > If by softly bind them you mean CPU affinity, ULE does this. It does not > support hard binding at the moment. I think KSEs are overengineered as a > mechanism for enforcing concurrency. Really a counter of running/runnable > threads in the proc would suffice. > > I'm starting to warm up to the idea of moving kse out of the rest of the > system. It could be confined to kern_mn.c or whatever it is eventually > called. kern_kse.c :-) M:N threads will run on any scheduler that knows about threads. This goes along with what we were discussing about separating the threadding system from the scheduling system. KSE threading is a misnomer. ALmost everywhere you see the term "KSE" being used in userland threading discussion it shuold be replaced by: "upcall context" (or UPCTX?) which is closely connected with a UTS instance. Originally KSEs were a simple method a fairness. Not perfect but simple and effective. By limiting the KSEs to the number of CPUs one could limit the ability of a process to flood the run queue. While it was envisionned as a part of splitting up the proc structure, it SHOULD have been envisionned as part of the scheduler. Unfortunatly we hadn't come up with the idea of having a separate upcall-context structure yet, so it was doing double duty as that as well, which clouded the picture. When that was split out as part of the threading system, the KSE that was left was plainly part of the scheduling system. (and an implementation detail at that) If we had had an upcall-context structure to start with, it is likely that I would have first gone for a simpler threads--only (but unfair) scheduler, and KSEs would have been only created when someone tried to make it fairer. :-) > > Cheers, > Jeff > > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >