From owner-freebsd-threads@FreeBSD.ORG Mon Jul 3 13:29:46 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9A6EE16A403; Mon, 3 Jul 2006 13:29:46 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-threads@freebsd.org, Daniel Eischen Date: Mon, 3 Jul 2006 21:29:23 +0800 User-Agent: KMail/1.8.2 References: <20060703101554.Q26325@fledge.watson.org> <200607032020.10993.davidxu@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607032129.23754.davidxu@freebsd.org> Cc: threads@freebsd.org, Robert Watson Subject: Re: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 13:29:47 -0000 On Monday 03 July 2006 20:29, Daniel Eischen wrote: > On Mon, 3 Jul 2006, David Xu wrote: > > On Monday 03 July 2006 19:48, Daniel Eischen wrote: > >> Yes, you have to support PTHREAD_PRIO_PROTECT, PTHREAD_PRIO_INHERIT > >> mutexes, and SCHED_RR, SCHED_FIFO, and SCHED_SPORADIC scheduling > >> (hopefully not under the restriction that you are a privileged user). > > > > I would tell you don't implement system scope thread in libpthread, > > because system scope thread does not work in the way you said here, > > it seems you are telling user that the libpthread is fully working in > > the way, but the reality is not, without a correct kernel support, > > I don't think you should introduce system scope thread into libpthread, > > please remove this feautre if you think libpthread should work in the > > way. > > I don't believe that system scope threads have to abide > by SCHED_RR, SCHED_FIFO, and SCHED_SPORADIC scheduling > since their contention scope is different. > using system native thread to get performance, using a second level scheduler hides and eliminates improvment made in kernel and throw away all hardwork done by kernel hacker. > This has no impact on libpthread. The KSE is the thing > that the kernel knows about and it can keep threads running > on the same KSE and assign KSEs to different CPUs, etc. > All the threads library has to do is keep threads running > on the same KSE. I've said this before, but you keep > making the same argument ;-) > you don't know, cpu soft affinity is not that simple, only kernel may guess what should be done, there is lots of detail, e.g, under heavy threaded IPC load, wake up a thread to local cpu will win, moving it to the original cpu the thread run will lost fresh cached data generated by current thread, in that load, every cpu has the application's hot code and static data structure cached, but new data is only available on the local cpu, I suggest you don't do that work in userland thread, it is a sort of time waste to repeat kernel scheduler function. > >> If you can those in libthr, I have no objection. However, these > >> are not as easy to do in 1:1. > > > > it depends on whether one has interest to implement it, nothing > > is impossible here, kernel has already turnstile code, this already > > made a bit forward. > > Are you going to do it? yes, but it is not that urgent.