Received: by 10.223.176.5 with SMTP id f5csp3012433wra; Mon, 5 Feb 2018 14:09:43 -0800 (PST) X-Google-Smtp-Source: AH8x225RjEVGs/XtTjsWGxRjh3/v+Sgd77p/HB4ghXKTAPvd4n8lTadj++em3T320xpGB0I2sQXT X-Received: by 10.98.12.144 with SMTP id 16mr244757pfm.147.1517868582977; Mon, 05 Feb 2018 14:09:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517868582; cv=none; d=google.com; s=arc-20160816; b=IB792NqDTGvqM6LfXUAT+rzXHeOaJ9otrruh3U6FK/nsrrl0zRLObUGuqrSNQhvR0q EHRA7sab2c+BguAXE8sz1bIUM9Ag0XjgHbzH28TSoIJiBT9/u0xFz/fPcw2jz5gqA0+p 8VyXLbahV8Fz/ynGroklYDcJ67wXK3054v3hKrIBsIh0159eVUXdgFGOUJhbYUC5oFC7 GessyMkxioA2ExX7na8lKJbctUrNTimz+npSg8K4iUi9mBjQsaXesFPwm+69vlTXZkYf gWXXo6D8ggA1m+cs4DrKd4W/lWxsYpNO43fc+TpTYOt0n//j8hcb36XpV2UnuerkpL3A jpoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=jeDA4n5HPLI5I2spV2dJI4NXCIh6LWg5Ghrgn64QqA4=; b=UKTq+tPUQw45iTMoJxDGzv31NGvIuty0yVL+7zUkFC/0/5srYqyi4AbUGcpHHNPXug YFwtHgLH83F5CPqP4QpChtjhGarLgOZvYP/creoq/MZF6XNtmXNY4p5G55zlJ9MbrDG2 tKNJWbl3BoI0oKAsv6C0JmPS54zhSNcwuu9M8gxeQq9EZ8eXsPYO4pBvk5ASj41NsFAu VFomzrSS/l5li9W7g0ooVfLAyDHkVjxFwfVu8AeY1yxy5F8SMa1bahyRVeV2uvrXOJRB neqYtsK8HfzxVJitlZ1jyoTYFq654iTQBSCBVHWDsfAQDDkRlOUEuXv6HyOL9LZR4V2u ENMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=tLjx7enn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4-v6si7430227plp.746.2018.02.05.14.09.27; Mon, 05 Feb 2018 14:09:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=tLjx7enn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751837AbeBEWIz (ORCPT + 99 others); Mon, 5 Feb 2018 17:08:55 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:36752 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750796AbeBEWIt (ORCPT ); Mon, 5 Feb 2018 17:08:49 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w15M6uwu067913; Mon, 5 Feb 2018 22:08:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=jeDA4n5HPLI5I2spV2dJI4NXCIh6LWg5Ghrgn64QqA4=; b=tLjx7enn7JXgk7srFkg0PIuYsAYVjCSj1HFDln6VWQldW6PsYo9YgwYnLpAqGs4oAzzw AyKPEG07fPVp8b5DKuV+WOKHOsu6X6o6Dcbf8WeEbzBQmzairfpRfy9h7EaSm4d+7Eis RaEwpC772z/itqS32mGIVk0VPZoUJPxZ4b1WdIDOan1rBeAeszFOC6oHFYqIF0kyOd7y EthEc7+do6JZO2SvfGHw52/F6LAjgtIDfufrL1VG0eUQZxRGNgBdpU2cGM11ED6fXjuW JwET6jC+6jHRjmUdig29h/RPrMIi90whDCfjd2U0NoM3bEPYmfmAJypnZJ9A+W+uidsc DQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2fxyny014d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Feb 2018 22:08:29 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w15M8S9m030669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Feb 2018 22:08:28 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w15M8RIh029659; Mon, 5 Feb 2018 22:08:27 GMT Received: from [10.132.91.87] (/10.132.91.87) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Feb 2018 14:08:27 -0800 Subject: Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance To: Peter Zijlstra Cc: Steven Sistare , linux-kernel@vger.kernel.org, mingo@redhat.com, dhaval.giani@oracle.com References: <20180129233102.19018-1-subhra.mazumdar@oracle.com> <20180201123335.GV2249@hirez.programming.kicks-ass.net> <911d42cf-54c7-4776-c13e-7c11f8ebfd31@oracle.com> <20180202171708.GN2269@hirez.programming.kicks-ass.net> <93db4b69-5ec6-732f-558e-5e64d9ba0cf9@oracle.com> <20180205121947.GW2269@hirez.programming.kicks-ass.net> From: Subhra Mazumdar Message-ID: <930364e4-bbfe-8c8f-d095-0dd4256a5104@oracle.com> Date: Mon, 5 Feb 2018 14:09:11 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180205121947.GW2269@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8796 signatures=668662 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050272 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/05/2018 04:19 AM, Peter Zijlstra wrote: > On Fri, Feb 02, 2018 at 09:37:02AM -0800, Subhra Mazumdar wrote: >> In the scheme of SMT balance, if the idle cpu search is done _not_ in the >> last run core, then we need a random cpu to start from. If the idle cpu >> search is done in the last run core we can start the search from last run >> cpu. Since we need the random index for the first case I just did it for >> both. > That shouldn't be too hard to fix. I think we can simply transpose the > CPU number. That is, something like: > > cpu' = core'_id + (cpu - core_id) > > should work for most sane cases. We don't give any guarantees this will > in fact work, but (almost) all actual CPU enumeration schemes I've seen > this should work for. > > And if it doesn't work, we're not worse of than we are now. > > I just couldn't readily find a place where we need to do this for cores > with the current code. But I think we have one place between LLCs where > it can be done: > > --- > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 7b6535987500..eb8b8d0a026c 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -6109,7 +6109,7 @@ static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int t > if (!static_branch_likely(&sched_smt_present)) > return -1; > > - for_each_cpu(cpu, cpu_smt_mask(target)) { > + for_each_cpu_wrap(cpu, cpu_smt_mask(target), target) { > if (!cpumask_test_cpu(cpu, &p->cpus_allowed)) > continue; > if (idle_cpu(cpu)) > @@ -6357,8 +6357,17 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f > if (cpu == prev_cpu) > goto pick_cpu; > > - if (wake_affine(affine_sd, p, prev_cpu, sync)) > - new_cpu = cpu; > + if (wake_affine(affine_sd, p, prev_cpu, sync)) { > + /* > + * Transpose prev_cpu's offset into this cpu's > + * LLC domain to retain the 'random' search offset > + * for for_each_cpu_wrap(). > + */ > + new_cpu = per_cpu(sd_llc_id, cpu) + > + (prev_cpu - per_cpu(sd_llc_id, prev_cpu)); > + if (unlikely(!cpus_share_cache(new_cpu, cpu))) > + new_cpu = cpu; > + } > } > > if (sd && !(sd_flag & SD_BALANCE_FORK)) { The pseudo random is also used for choosing a random core to compare with, how will transposing achieve that? Thanks, Subhra