From owner-freebsd-current@FreeBSD.ORG Fri Feb 13 14:00:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DAF016A4CE; Fri, 13 Feb 2004 14:00:22 -0800 (PST) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id C58E543D1D; Fri, 13 Feb 2004 14:00:21 -0800 (PST) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [192.168.36.3]) by sakura.ninth-nine.com (8.12.10/8.12.10/NinthNine) with SMTP id i1DM00iA064214; Sat, 14 Feb 2004 07:00:00 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 14 Feb 2004 07:00:00 +0900 (JST) Message-Id: <200402132200.i1DM00iA064214@sakura.ninth-nine.com> From: Norikatsu Shigemura To: Jeff Roberson In-Reply-To: <20040213063139.71298ea9.taku@cent.saitama-u.ac.jp> References: <20040213063139.71298ea9.taku@cent.saitama-u.ac.jp> X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Maho Nakata cc: Martin Blapp cc: current@FreeBSD.org cc: Daichi Goto Subject: Re: SCHED_ULE sometimes puts P_SA processes into ksq_next unnecessarily X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 13 Feb 2004 22:00:22 -0000 Hi jeff. Do you think? This has a very effort on OOo's compile problem. On Fri, 13 Feb 2004 06:31:39 +0900 Taku YAMAMOTO wrote: > I observed that SCHED_ULE doesn't give fair amount of CPU time to processes > which are using scheduler-activation-based threads when other > (semi-)CPU-intensive, non-P_SA processes are running. > # for example, browsing a complicated web page while compiling some > # amount of code with nice 0. > After spending several hours, I finally tracked it down to the following > code in sched_ule.c: > > **** snip **** > void > sched_switch(struct thread *td) > { > **** snip **** > if (TD_IS_RUNNING(td)) { > if (td->td_proc->p_flag & P_SA) { > kseq_load_rem(KSEQ_CPU(ke->ke_cpu), ke); > setrunqueue(td); > } else > kseq_runq_add(KSEQ_SELF(), ke); > **** snip **** > void > sched_add(struct thread *td) > { > **** snip **** > case PRI_TIMESHARE: > if (SCHED_CURR(kg, ke)) > ke->ke_runq = kseq->ksq_curr; > else > ke->ke_runq = kseq->ksq_next; > break; > **** snip **** > > The problem is that setrunqueue() calls sched_add(), which resets ke_runq, > thus non-interactive threads are likely to be put into ksq_next regardless > of however much slices remaining. > On the contrary, threads of !P_SA processes stay in ksq_curr unless slices > have been expired, since !P_SA case bypass setrunqueue() => sched_add() > path. > In order to reduce the difference, I tested three different strategies. > 1. preserve ke_runq in P_SA case (ule_runq_preserve.patch) > This became a bit hackish, but I felt the characteristics of ULE were > well preserved. I confirmed and tested /usr/ports/japanese/openoffice-1.1 in this way. OOo's regcomp (on build) don't overrun. This is a good news for OOo users. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11014 nork -8 0 22420K 8464K biowr 0:01 6.25% 6.25% regcomp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 2. set ke_runq to ksq_next if the given thread is considered > non-interactive in !P_SA case (ule_runq_reset.patch) > I felt that the scheduler behaves a bit like the SCHED_4BSD does, which > I think is not good. > 3. use setrunqueue() (= sched_add()) in !P_SA case, too, like SCHED_4BSD > does (ule_sameas_sa.patch) > I felt that the scheduler behaves much more like the SCHED_4BSD (read: > good characteristics of ULE seemed to fade out), but it might be > scientifically correct. > In either way, P_SA processes were given reasonable amount of CPU time > relative to the !P_SA processes, while with unmodified scheduler, most of > CPU time was eaten up by cc1plus(PRI=136..139) and nearly zero CPU to > epiphany-bin(PRI=92 or so). > # checked with top, epiphany+libpthread and compiling 4k-lines C++ program > # with CXXFLAGS='-pipe -O3 etc...', took several minutes on Pen2@300MHz > Since I am totally unfamilier with the scheduler things, all of the three > can be completely wrong or irrelevant to the problem. But I hope one of > them brings some lights to scheduler gulus. > Thank you for reading, > taku > -- > -|-__ YAMAMOTO, Taku > | __ < > Post Scriptum: Sorry for no concrete statistics :)