From owner-freebsd-stable@FreeBSD.ORG Sat Dec 24 11:15:59 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D36D106566C for ; Sat, 24 Dec 2011 11:15:59 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by mx1.freebsd.org (Postfix) with SMTP id E15768FC14 for ; Sat, 24 Dec 2011 11:15:58 +0000 (UTC) Received: from [98.139.91.68] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 24 Dec 2011 11:15:58 -0000 Received: from [208.71.42.211] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 24 Dec 2011 11:15:58 -0000 Received: from [127.0.0.1] by smtp222.mail.gq1.yahoo.com with NNFMP; 24 Dec 2011 11:15:58 -0000 X-Yahoo-Newman-Id: 710493.53393.bm@smtp222.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3ISS6S0VM1kw.uLrWJntn9y.h3eZLyHU5s6J0gz6jJJiLAb jlClg6XNdqJNRp1IExCjpS4E33m6iHBrvAr76eH63ntJifcD2i_qkj.t_QNO tecq.0.5SLaFwR5nt0ZhBTMFHgVxpDuJhb3f_PUFpGaGXmR.KguOS.5fkhPK HHlVjqpNsN30YmQNnG5mJ2DY.xlM6.rRl.QdRPzzGmYCTIZNLvXq2Z1c5bkt 3gg0eXtymHvViPmxnKvufUjZVvk8EBw8Hvs9dLgy7rMlW0YNCnJCegfphJop 0PcFq1L5AKXUdHJUYeykSFgqHo7kgQxfLh3S5uE.wDtPFg8sstRmTYW7m5Rv 15qSeQVdop2cdCRPzVhzAxxII_80BwdqMz.qNMp4vrXb385Hudqo_2uAlpgJ weGRx2N9oR7sSEY0- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.141.239 with plain) by smtp222.mail.gq1.yahoo.com with SMTP; 24 Dec 2011 03:15:58 -0800 PST Message-ID: <4EF5B46D.5030901@freebsd.org> Date: Sat, 24 Dec 2011 12:15:57 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4EE1EAFE.3070408@m5p.com> <20111215215554.GA87606@troutmask.apl.washington.edu> <20111222005250.GA23115@troutmask.apl.washington.edu> <20111222103145.GA42457@onelab2.iet.unipi.it> <20111222184531.GA36084@troutmask.apl.washington.edu> <4EF37E7B.4020505@FreeBSD.org> <20111222194740.GA36796@troutmask.apl.washington.edu> <20111223191146.GA56232@troutmask.apl.washington.edu> <4EF50890.8030509@FreeBSD.org> In-Reply-To: <4EF50890.8030509@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-stable@FreeBSD.org, Steve Kargl Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 11:15:59 -0000 Am 24.12.2011 00:02, schrieb Andriy Gapon: > on 24/12/2011 00:49 Adrian Chadd said the following: >> Does ULE care (much) if the nodes are hyperthreading or real cores? >> Would that play a part in what it tries to schedule/spread? > > An answer to this part from the theory. > ULE does care about physical topology of the (logical) CPUs. > So, for example, four cores are not the same as two core with two hw threads > from ULE's perspective. Still, ULE tries to eliminate any imbalances between > the CPU groups starting from the top level (e.g. CPU packages in a multi-socket > system) and all the way down to the individual (logical) CPUs. > Thus, given enough load (L >= N) there should not be an idle CPU in the system > whatever the topology. Modulo bugs, of course, as always. I tried to locate the old message, where somebody explained why the topology lead to a thread being selected for migration, re-assigned and then on another topology level was swapped back and ended on just the core it had already been running on. The analysis was quite detailed and it may well have been part of that discussion back in 2008 that Steve Kargl mentioned ... This problem could be fixed by adding a slight degree if randomness. But if IIRC, a deterministic solution might also be possible, which just takes care not to put a thread back on the core it previously had been running on, if it has been determined that the thread should be migrated to a different core, before. Sorry for not being able to point to the old message that contained the analysis of this problem. Regards, STefan