From owner-freebsd-current@FreeBSD.ORG Tue Apr 10 19:13:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F13E5106564A; Tue, 10 Apr 2012 19:13:47 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D57CD8FC08; Tue, 10 Apr 2012 19:13:46 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so138770bkc.13 for ; Tue, 10 Apr 2012 12:13:46 -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=8ZWDssOPUTIzmiGTu/VNGj/gU8fSY+gG7N3Vg9PLcuo=; b=yTcvgifT7Hagq6FIPBUvAQuzSyDeae1MNXHhywmB96czUClyI41D0Neau65R1lOW/t bxF1eKoypAzIm3xBayCZvpoWEz2klHMfh9qy1rMyyZSmlxfbm92cAw3NSqo+00j+S4uR DMTQ6PSp1pNRQgHzE0X38zjPnF+FrO9MxQclY9DB7WXKto8J0pPO+v53htFMH21JSBMQ tu/eBTI2PErQthzzmcmsgJQxMOYsh/iocjGi3Xcc7z93vSUzMGnTsvqQDJxTtSlAX2Ck qVfPb1CCm+HKpG593FY2QoV8/SYbBwhEMDNJMq5uh1yI/PdmZNaWijogd4Z7uVJCVWLU LKYw== Received: by 10.204.156.216 with SMTP id y24mr5154693bkw.60.1334085225856; Tue, 10 Apr 2012 12:13:45 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id c4sm408768bkh.0.2012.04.10.12.13.43 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 12:13:44 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F848666.8030308@FreeBSD.org> Date: Tue, 10 Apr 2012 22:13:42 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120226 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> <4F3E8858.4000001@FreeBSD.org> <4F7DE863.6080607@FreeBSD.org> <4F833F3D.7070106@FreeBSD.org> <4F846B74.9080504@FreeBSD.org> <4F8473B7.9080000@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only 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: Tue, 10 Apr 2012 19:13:48 -0000 On 04/10/12 21:46, Arnaud Lacombe wrote: > On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin wrote: >> On 04/10/12 20:18, Alexander Motin wrote: >>> On 04/10/12 19:58, Arnaud Lacombe wrote: >>>> 2012/4/9 Alexander Motin: >>>>> I have strong feeling that while this test may be interesting for >>>>> profiling, >>>>> it's own results in first place depend not from how fast scheduler >>>>> is, but >>>>> from the pipes capacity and other alike things. Can somebody hint me >>>>> what >>>>> except pipe capacity and context switch to unblocked receiver prevents >>>>> sender from sending all data in batch and then receiver from >>>>> receiving them >>>>> all in batch? If different OSes have different policies there, I think >>>>> results could be incomparable. >>>>> >>>> Let me disagree on your conclusion. If OS A does a task in X seconds, >>>> and OS B does the same task in Y seconds, if Y> X, then OS B is just >>>> not performing good enough. Internal implementation's difference for >>>> the task can not be waived as an excuse for result's comparability. >>> >>> >>> Sure, numbers are always numbers, but the question is what are they >>> showing? Understanding of the test results is even more important for >>> purely synthetic tests like this. Especially when one test run gives 25 >>> seconds, while another gives 50. This test is not completely clear to me >>> and that is what I've told. >> >> Small illustration to my point. Simple scheduler tuning affects thread >> preemption policy and changes this test results in three times: >> >> mav@test:/test/hackbench# ./hackbench 30 process 1000 >> Running with 30*40 (== 1200) tasks. >> Time: 9.568 >> >> mav@test:/test/hackbench# sysctl kern.sched.interact=0 >> kern.sched.interact: 30 -> 0 >> mav@test:/test/hackbench# ./hackbench 30 process 1000 >> Running with 30*40 (== 1200) tasks. >> Time: 5.163 >> >> mav@test:/test/hackbench# sysctl kern.sched.interact=100 >> kern.sched.interact: 0 -> 100 >> mav@test:/test/hackbench# ./hackbench 30 process 1000 >> Running with 30*40 (== 1200) tasks. >> Time: 3.190 >> >> I think it affects balance between pipe latency and bandwidth, while test >> measures only the last. It is clear that conclusion from these numbers >> depends on what do we want to have. >> > I don't really care on this point, I'm only testing default values, or > more precisely, whatever developers though default values would be > good. > > Btw, you are testing 3 differents configuration. Different results are > expected. What worries me more is the rather the huge instability on > the *same* configuration, say on a pipe/thread/70 groups/600 > iterations run, where results range from 2.7s[0] to 7.4s, or a > socket/thread/20 groups/1400 iterations run, where results range from > 2.4s to 4.5s. Due to reason I've pointed in my first message this test is _extremely_ sensitive to context switch interval. The more aggressive scheduler switches threads, the smaller will be pipe latency, but the smaller will be also bandwidth. During test run scheduler all the time recalculates interactivity index for each thread, trying to balance between latency and switching overhead. With hundreds of threads running simultaneously and interfering with each other it is quite unpredictable process. -- Alexander Motin