From owner-freebsd-current@FreeBSD.ORG Mon Aug 20 08:32:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 249C6106564A; Mon, 20 Aug 2012 08:32:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E8C7D14DF92; Mon, 20 Aug 2012 08:32:54 +0000 (UTC) Message-ID: <5031F636.1020405@FreeBSD.org> Date: Mon, 20 Aug 2012 01:32:54 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Alexander Motin References: <157941699.20120815004542@serebryakov.spb.ru> <502AE8B5.9090106@FreeBSD.org> <502B775D.7000101@FreeBSD.org> In-Reply-To: <502B775D.7000101@FreeBSD.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , lev@freebsd.org, current@freebsd.org Subject: Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck? 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: Mon, 20 Aug 2012 08:32:55 -0000 On 08/15/2012 03:18, Alexander Motin wrote: > On 15.08.2012 03:09, Doug Barton wrote: >> On 08/14/2012 12:20 PM, Adrian Chadd wrote: >>> Would you be willing to compile a kernel with KTR so you can capture >>> some KTR scheduler dumps? >>> >>> That way the scheduler peeps can feed this into schedgraph.py (and you >>> can too!) to figure out what's going on. >>> >>> Maybe things aren't being scheduled correctly and the added latency is >>> killing performance? >> >> You might also try switching to SCHED_ULE to see if it helps. >> >> Although, in the last few months as mav has been converging the 2 I've >> started to see the same problems I saw on my desktop systems previously >> re-appear even using ULE. For example, if I'm watching an AVI with VLC >> and start doing anything that generates a lot of interrupts (like moving >> large quantities of data from one disk to another) the video and sound >> start to skip. Also, various other desktop features (like menus, window >> switching, etc.) start to take measurable time to happen, sometimes >> seconds. >> >> ... and lest you think this is just a desktop problem, I've seen the >> same scenario on 8.x systems used as web servers. With ULE they were >> frequently getting into peak load situations that created what I called >> "mini thundering herd" problems where they could never quite get caught >> up. Whereas switching to 4BSD the same servers got into high-load >> situations less often, and they recovered on their own in minutes. > > It is quite pointless to speculate without real info like mentioned > above KTR_SCHED traces. I'm sorry, you're quite wrong about that. In the cases I mentioned, and in about 2 out of 3 of the cases where users reported problems and I suggested that they try 4BSD, the results were clear. This obviously points out that there is a serious problem with ULE, and if I were the one who was responsible for that code I would be looking at ways of helping users figure out where the problems are. But that's just me. > Main thing I've learned about schedulers, things > there never work as you expect. There are two many factors are relations > to predict behavior in every case. In the web hosting case that I mentioned, I purposely kept every other factor consistent; and changed only s/ULE/4BSD/. The results were both clear and consistent. > What's about playing AVIs and using other GUIs, key word here and for > ULE in general is interactivity. ULE gives huge boost to threads it > counts interactive. I'm not using ULE. I haven't for over a year. Sorry if I wasn't clear. > If somebody still wish area for experiments, there is always some: > - if you want video player to not lag, set negative nice for it (ULE is > not a magician to guess user wishes); At the same time, I don't have these problems on my Linux systems, and I don't need to adjust anything. Not to mention that given how web servers are one of our main server implementations, the fact that we have what seems to be a serious performance problem with out default scheduler in that use case seems like an issue that we would want to address. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)