From owner-freebsd-current@FreeBSD.ORG Sun Oct 19 02:18:20 2003 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 943F316A4B3 for ; Sun, 19 Oct 2003 02:18:20 -0700 (PDT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 5243943FCB for ; Sun, 19 Oct 2003 02:18:19 -0700 (PDT) (envelope-from ltning@anduin.net) Received: (qmail 94054 invoked by uid 85); 19 Oct 2003 09:18:18 -0000 Received: from ltning@anduin.net by anduin.net by uid 82 with qmail-scanner-1.20rc1 (clamscan: 0.60. Clear:RC:1:. Processed in 1.816087 secs); 19 Oct 2003 09:18:18 -0000 X-Qmail-Scanner-Mail-From: ltning@anduin.net via anduin.net X-Qmail-Scanner: 1.20rc1 (Clear:RC:1:. Processed in 1.816087 secs) Received: from ranger.anduin.net (HELO anduin.net) (213.238.32.74) by anduin.net with SMTP; 19 Oct 2003 09:18:15 -0000 Message-ID: <3F9256B8.10504@anduin.net> Date: Sun, 19 Oct 2003 11:17:44 +0200 From: Eirik Oeverby User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031017 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Roberson , current@freebsd.org References: <20031017022244.W30029-100000@mail.chesapeake.net> In-Reply-To: <20031017022244.W30029-100000@mail.chesapeake.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: More ULE bugs fixed. 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: Sun, 19 Oct 2003 09:18:20 -0000 X-List-Received-Date: Sun, 19 Oct 2003 09:18:20 -0000 As a side note/question: Is there any way to figure out which ULE version I'm running in a precompiled kernel? I just nuked my src tree by accident, and am not sure if i'm on 1.65 or something older.. If there is no way, is this perhaps an idea? Thanks, /Eirik Jeff Roberson wrote: > On Fri, 17 Oct 2003, Bruce Evans wrote: > > >>How would one test if it was an improvement on the 4BSD scheduler? It >>is not even competitive in my simple tests. > > > [scripts results deleted] > > >>Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the >>obj and depend stages. These stages have little parallelism. SCHED_ULE >>was only 19% slower for the all stage. It apparently misses many >>oppurtunities to actually run useful processes. This may be related >>to /usr being nfs mounted. There is lots of idling waiting for nfs >>even in the SCHED_4BSD case. The system times are smaller for SCHED_ULE, >>but this might not be significant. E.g., zeroing pages can account >>for several percent of the system time in buildworld, but on unbalanced >>systems that have too much idle time most page zero gets done in idle >>time and doesn't show up in the system time. > > > At one point ULE was at least as fast as 4BSD and in most cases faster. > This is a regression. I'll sort it out soon. > > > >>Test 1 for fair scheduling related to niceness: >> >> for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 >> do >> nice -$i sh -c "while :; do echo -n;done" & >> done >> top -o time >> >>[Output deleted]. This shows only a vague correlation between niceness >>and runtime for SCHED_ULE. However, top -o cpu shows a strong correlation >>between %CPU and niceness. Apparently, %CPU is very innacurate and/or >>not enough history is kept for long-term scheduling to be fair. >> >>Test 5 for fair scheduling related to niceness: >> >> for i in -20 -16 -12 -8 -4 0 4 8 12 16 20 >> do >> nice -$i sh -c "while :; do echo -n;done" & >> done >> time top -o cpu >> >>With SCHED_ULE, this now hangs the system, but it worked yesterday. Today >>it doesn't get as far as running top and it stops the nfs server responding. >>To unhang the system and see what the above does, run a shell at rtprio 0 >>and start top before the above, and use top to kill processes (I normally >>use "killall sh" to kill all the shells generated by tests 1-5, but killall >>doesn't work if it is on nfs when the nfs server is not responding). > > > 661 root 112 -20 900K 608K RUN 0:24 27.80% 27.64% sh > 662 root 114 -16 900K 608K RUN 0:19 12.43% 12.35% sh > 663 root 114 -12 900K 608K RUN 0:15 10.66% 10.60% sh > 664 root 114 -8 900K 608K RUN 0:11 9.38% 9.33% sh > 665 root 115 -4 900K 608K RUN 0:10 7.91% 7.86% sh > 666 root 115 0 900K 608K RUN 0:07 6.83% 6.79% sh > 667 root 115 4 900K 608K RUN 0:06 5.01% 4.98% sh > 668 root 115 8 900K 608K RUN 0:04 3.83% 3.81% sh > 669 root 115 12 900K 608K RUN 0:02 2.21% 2.20% sh > 670 root 115 16 900K 608K RUN 0:01 0.93% 0.93% sh > > I think you cvsup'd at a bad time. I fixed a bug that would have caused > the system to lock up in this case late last night. On my system it > freezes for a few seconds and then returns. I can stop that by turning > down the interactivity threshold. > > Thanks, > Jeff > > >>Bruce >>_______________________________________________ >>freebsd-current@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"