From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 01:16:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01197106564A for ; Sat, 20 Nov 2010 01:16:41 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A5F0A8FC0C for ; Sat, 20 Nov 2010 01:16:40 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PJc4F-0004Pi-L2 for freebsd-current@freebsd.org; Sat, 20 Nov 2010 02:16:39 +0100 Received: from cpe-188-129-101-155.dynamic.amis.hr ([188.129.101.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Nov 2010 02:16:39 +0100 Received: from ivoras by cpe-188-129-101-155.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Nov 2010 02:16:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sat, 20 Nov 2010 02:16:24 +0100 Lines: 37 Message-ID: References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <4CE58CD8.2000407@mail.zedat.fu-berlin.de> <20101120004955.68c8af6a.taku@tackymt.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-101-155.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20101120004955.68c8af6a.taku@tackymt.homeip.net> Cc: freebsd-performance@freebsd.org, freebsd-stable@freebsd.org Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 01:16:41 -0000 On 11/19/10 16:49, Taku YAMAMOTO wrote: > I have a dumb local hack to grant ts_slice proportional to the duration > the waking thread slept rather than unconditionally reset to sched_slice. > > > --- sys/kern/sched_ule.c.orig > +++ sys/kern/sched_ule.c > @@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *td) > u_int hzticks; > > hzticks = (ticks - slptick)<< SCHED_TICK_SHIFT; > + if (hzticks> SCHED_SLP_RUN_MAX) > + hzticks = SCHED_SLP_RUN_MAX; > ts->ts_slptime += hzticks; > + /* Grant additional slices after we sleep. */ > + ts->ts_slice += hzticks / tickincr; > + if (ts->ts_slice > sched_slice) > + ts->ts_slice = sched_slice; If I read it correctly, now instead of the slice given to the thread being always sched_slice, now it is reduced to a value smaller than sched_slice based on how long did the thread sleep? How does that help? > sched_interact_update(td); > sched_pctcpu_update(ts); > } > - /* Reset the slice value after we sleep. */ > - ts->ts_slice = sched_slice; > sched_add(td, SRQ_BORING); > } > > >