From owner-freebsd-threads@FreeBSD.ORG Sat Feb 19 13:44:48 2005 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 DEEB116A4CE; Sat, 19 Feb 2005 13:44:48 +0000 (GMT) Received: from mx.highway.ne.jp (pip7.usen.ad.jp [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DB3043D4C; Sat, 19 Feb 2005 13:44:48 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.195.104.17] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1D2Uuc-0007gT-SZ; Sat, 19 Feb 2005 22:44:47 +0900 Message-ID: <421742AC.9050509@highway.ne.jp> Date: Sat, 19 Feb 2005 22:44:12 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <42173C82.7040408@highway.ne.jp> <42174126.5000006@freebsd.org> In-Reply-To: <42174126.5000006@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: threads@freebsd.org Subject: Re: thread accounting in libpthread 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: Sat, 19 Feb 2005 13:44:49 -0000 Yes. It is fair scheduling under console. My result is under xterm. Could you run it under xterm or any other x11 terminal? David Xu wrote: > I have run your program, here is the result: > > ... > thread 04: countup > thread 00: countup > thread 01: countup > -------------------- > thread 00: 553150 > thread 01: 562367 > thread 02: 553351 > thread 03: 532770 > thread 04: 542718 > -------------------- > > It is fair scheduling. I run it under console and no other programs > are eating CPU > time, note that I didn't run it under X11 terminal. > > David Xu > > Kazuaki Oda wrote: > >> Daniel Eischen wrote: >> >>> On Sat, 19 Feb 2005, Kazuaki Oda wrote: >>> >>> >>>> And while looking at thr_kern.c, I've had one more question. >>>> In kse_switchout_thread, after calling thr_accounting thread is placed >>>> at the tail of run queue or at the head of it according to >>>> thread->slice_usec. >>>> But in kse_check_completed, thread is just placed at the tail of >>>> run queue. >>>> Is there any reason why thread is not placed at the head of run >>>> queue in >>>> case of thread->slice_usec != -1? >>>> >>> >>> >>> >>> Because it already blocked and we don't want to needlessly >>> switch out a currently running thread that hasn't used its >>> quantum. >>> >>> >>> >> >> Blocked? I think that completed threads are *not* blocked and they >> are ready >> to run except for suspended. And, kse_check_completed could be >> called after >> calling kse_wait. In this case there is currently no running thread. >> >> The reason why I am researching libpthread is that the attached >> program shows >> -------------------- >> thread 00: 55666 >> thread 01: 1161 >> thread 02: 1112 >> thread 03: 1112 >> thread 04: 55494 >> -------------------- >> on xterm on my UP machine. This is a unexpected result. It seems to >> me that >> libpthread does unfair scheduling. But on SMP machine that program >> shows >> expected result and on console too... >> >> >> -------------------- >> Kazuaki Oda >>