From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 6 14:13:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA62106566B; Fri, 6 Apr 2012 14:13:20 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D35E8FC12; Fri, 6 Apr 2012 14:13:19 +0000 (UTC) Received: by lagv3 with SMTP id v3so3256993lag.13 for ; Fri, 06 Apr 2012 07:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0HKZXzzhla0zLLcbztegWtUXI92ZPMj/ck0vAu6yrBM=; b=Bo4hm4+ERIOFBL9nP7Kms0U1ki9RU6AyXEH6EZlYk2lz/hqPNCLnIiukqdXexZAm1Y Xb48ZTQgub5ocus7UA/oGNv3yOaZ30nIepAS2jxct95Y0LDDtJNhd8Ta4nXJ0S7GMECb slstf2QDThU9MPztOY6/Q3iIQteWWATt9QHFPIjylTc9ukYjBl0x+LmtxLdg5sDr7x8E 3nsPhL8xxtqJpEi8zmG3WzbgBn6HZg55Z2mEf2Be/egHzqSkH2uLaH/tjxy3K4P0+nMz O0HrdQB8IZVWMVo96SFa9IhwEegzQxDoBNfBScnmXAzXveiIlEKNsrAPqLzh3R3IrOga t+Og== MIME-Version: 1.0 Received: by 10.152.103.239 with SMTP id fz15mr8742722lab.42.1333721598380; Fri, 06 Apr 2012 07:13:18 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.93.138 with HTTP; Fri, 6 Apr 2012 07:13:18 -0700 (PDT) In-Reply-To: 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> Date: Fri, 6 Apr 2012 15:13:18 +0100 X-Google-Sender-Auth: KJiZxTVK21Sfhjp69bIgLvdGm2o Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Florian Smeets , freebsd-hackers@freebsd.org, Alexander Motin , Andriy Gapon , FreeBSD current , Jeff Roberson Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:13:21 -0000 Il 05 aprile 2012 19:12, Arnaud Lacombe ha scritto: > Hi, > > [Sorry for the delay, I got a bit sidetrack'ed...] > > 2012/2/17 Alexander Motin : >> On 17.02.2012 18:53, Arnaud Lacombe wrote: >>> >>> On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin =C2= =A0wrote: >>>> >>>> On 02/15/12 21:54, Jeff Roberson wrote: >>>>> >>>>> On Wed, 15 Feb 2012, Alexander Motin wrote: >>>>>> >>>>>> I've decided to stop those cache black magic practices and focus on >>>>>> things that really exist in this world -- SMT and CPU load. I've >>>>>> dropped most of cache related things from the patch and made the res= t >>>>>> of things more strict and predictable: >>>>>> http://people.freebsd.org/~mav/sched.htt34.patch >>>>> >>>>> >>>>> This looks great. I think there is value in considering the other >>>>> approach further but I would like to do this part first. It would be >>>>> nice to also add priority as a greater influence in the load balancin= g >>>>> as well. >>>> >>>> >>>> I haven't got good idea yet about balancing priorities, but I've >>>> rewritten >>>> balancer itself. As soon as sched_lowest() / sched_highest() are more >>>> intelligent now, they allowed to remove topology traversing from the >>>> balancer itself. That should fix double-swapping problem, allow to kee= p >>>> some >>>> affinity while moving threads and make balancing more fair. I did numb= er >>>> of >>>> tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 an= d >>>> 16 >>>> threads everything is stationary as it should. With 9 threads I see >>>> regular >>>> and random load move between all 8 CPUs. Measurements on 5 minutes run >>>> show >>>> deviation of only about 5 seconds. It is the same deviation as I see >>>> caused >>>> by only scheduling of 16 threads on 8 cores without any balancing need= ed >>>> at >>>> all. So I believe this code works as it should. >>>> >>>> Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch >>>> >>>> I plan this to be a final patch of this series (more to come :)) and i= f >>>> there will be no problems or objections, I am going to commit it (exce= pt >>>> some debugging KTRs) in about ten days. So now it's a good time for >>>> reviews >>>> and testing. :) >>>> >>> is there a place where all the patches are available ? >> >> >> All my scheduler patches are cumulative, so all you need is only the las= t >> mentioned here sched.htt40.patch. >> > You may want to have a look to the result I collected in the > `runs/freebsd-experiments' branch of: > > https://github.com/lacombar/hackbench/ > > and compare them with vanilla FreeBSD 9.0 and -CURRENT results > available in `runs/freebsd'. On the dual package platform, your patch > is not a definite win. > >> But in some cases, especially for multi-socket systems, to let it show i= ts >> best, you may want to apply additional patch from avg@ to better detect = CPU >> topology: >> https://gitorious.org/~avg/freebsd/avgbsd/commit/6bca4a2e4854ea3fc275946= a023db65c483cb9dd >> > test I conducted specifically for this patch did not showed much improvem= ent... Can you please clarify on this point? The test you did included cases where the topology was detected badly against cases where the topology was detected correctly as a patched kernel (and you still didn't see a performance improvement), in terms of cache line sharing? Attilio --=20 Peace can only be achieved by understanding - A. Einstein