From owner-freebsd-current@FreeBSD.ORG Mon Aug 20 13:32:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0144106566C; Mon, 20 Aug 2012 13:32:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id D01BB8FC15; Mon, 20 Aug 2012 13:32:20 +0000 (UTC) Received: by eaak11 with SMTP id k11so2136001eaa.13 for ; Mon, 20 Aug 2012 06:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UUQ999bsigvjylyqCfIotwsOZq7twjh4eLJi7RPUW/g=; b=vB/+dVHf9t23S+GZj8UIUvY8Cz0/Lqztt5UjGxcvSXGIKri9sv3ZanmmAI37UGwMt5 n+V4/A+cTSh3zZKLKuIEER3oAf33XwGCwjVlRAriO+ATGLk2qWHTXgIVN5dZ73U1xuTp JzcbqpE4oLLtkAj0VLYuh32Kgxa4RJ4jAUprmsE2ahlVxtDGwOtBTW9OZZP27gRSLzp9 4loluZkW4+iENrGWScXTohbrLdJtHWHJXU9TMXvnl5ZRLZNdMNaDu9tqrcWAK2+rhwZo F4SICluGP9oMx1cAJXHjiSR8TT4OSssaYKCcr4vLPHseBIhHCuK0mq2YY5Qn21+MuKzy Gaiw== Received: by 10.14.219.198 with SMTP id m46mr8708579eep.18.1345469539533; Mon, 20 Aug 2012 06:32:19 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPS id y1sm42026154eel.0.2012.08.20.06.32.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 06:32:18 -0700 (PDT) Sender: Alexander Motin Message-ID: <50323C5F.5090109@FreeBSD.org> Date: Mon, 20 Aug 2012 16:32:15 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Doug Barton References: <157941699.20120815004542@serebryakov.spb.ru> <502AE8B5.9090106@FreeBSD.org> <502B775D.7000101@FreeBSD.org> <5031F636.1020405@FreeBSD.org> <50320A9E.5070303@FreeBSD.org> <503210A1.7010803@FreeBSD.org> In-Reply-To: <503210A1.7010803@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 13:32:22 -0000 On 20.08.2012 13:25, Doug Barton wrote: > On 08/20/2012 02:59, Alexander Motin wrote: >> On 20.08.2012 11:32, Doug Barton wrote: >>> 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. >> >> I am not telling anything bad about 4BSD. > > Yes, I get that, but thanks for making it clear. > >> Choice is provided because >> they are indeed different and none is perfect. > > ... which is why I'm asking you to stop making them more the same until > we get a better idea of what the issues are. I have no plans to converge them. I've just found problem in ULE, that was replicated into 4BSD and it would be strange to fix one without another. But fixing it exposed another old problem specific to 4BSD, which I fixed reusing logically equivalent code from ULE. I saw no reason to reinvent a wheel there, same as to not fix obvious bug. Sure, it can change behavior in some way, but ULE is not guilty. -- Alexander Motin