Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp779091ybg; Fri, 12 Jun 2020 14:36:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyIgYVSISS7wImnwGfoHb/bu8UlYVyIRW/Knx5MBuCiR7iTQBJwFOwn9KYyufs1BG+JsMWa X-Received: by 2002:a05:6402:34e:: with SMTP id r14mr13691842edw.351.1591997796593; Fri, 12 Jun 2020 14:36:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591997796; cv=none; d=google.com; s=arc-20160816; b=HAn9Spo5nzCiC5cOJT3n3xSXNHVsmVdt2Ktogl2KoRMFjwLE+Gr6byXJZPaAMwJXke TB/qBn0H8mHrX1BI7HLjpnA1+9T3tKhZM2K5+J4/Ku3syRI8GdVFiR5dAdit5z5YUYY2 S5NSt8vBhJ3pLVQ2CVPmamuECs897dFN8so95MEtlzaPh097V3O7r6cVVKBuIOmKhsBZ AQ8UZQ3dnI4314h0oIY4quOdaHyDcDqFbTkDgzlmlRZa66id3b3fDucCaTY8rvDjRQIJ lllfpiKWI26WWjFtiNziZrlMHkvDdMeQJ7bQqQ0O7PsGd4J+kiL9GSYx1FiYp6SrKyU3 zXlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hfr41w//Iq6L4D29Brj7mYe/GuqFaOrY8l4abvR0PaM=; b=tnVXgPzIYu2b+xL8L3b4Ew1Co/A+ZvhmTCUYEDoABUteQoGVT1KYW9AZSDSBNA6MYt GPTF+AJf6lwwrjhf09FzYT1NcE0Q5Blb9jaWHCQw9c5fgzKVbNcw4hwkLm5u169ADrox iBFJB0Z2ujUjdXKIh2a89JgFYVJ/vYLGJcd7I8YSvDVOXRNeehM25YaYpSe2q3+W0wHQ LCO5EXoIWF4d0R9xT/fUcxw28q0VAU1gZh1LXLKAiXPD/Q2n7ilGPKjMEs75eYi64SrY o7zjkpULECAngl9Xh5+j3/qOjkp3BtaO6+/Pyos0QImoqT5B5ffm+qC3Y8v7Jj+nOXbk SaCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@digitalocean.com header.s=google header.b=gxmrCvV5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=digitalocean.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zb3si4671087ejb.610.2020.06.12.14.36.13; Fri, 12 Jun 2020 14:36:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@digitalocean.com header.s=google header.b=gxmrCvV5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=digitalocean.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726319AbgFLVcQ (ORCPT + 99 others); Fri, 12 Jun 2020 17:32:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36386 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726302AbgFLVcP (ORCPT ); Fri, 12 Jun 2020 17:32:15 -0400 Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1CADC03E96F for ; Fri, 12 Jun 2020 14:32:13 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id g5so8488858otg.6 for ; Fri, 12 Jun 2020 14:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitalocean.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hfr41w//Iq6L4D29Brj7mYe/GuqFaOrY8l4abvR0PaM=; b=gxmrCvV5G1tix2wqvkHSkUTHm+oaINr1b8AyqOq6bo39chOaqPPPR81ikDfZtLP83n OMthIbM/WujWSlAItMzXDr6C+faqOEqz6CEoMrH4kAWzykiX2XbMxjXba2/xqDbXdPfk TloJErwLik7sc+O+HBoZQ0keJVlRhGW2NBXHU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hfr41w//Iq6L4D29Brj7mYe/GuqFaOrY8l4abvR0PaM=; b=b9LMS3sqQBbn4FMHd1oD0ty2jsKNFQGKFj5a6YRjToNJebVn/o7/Y1j2OD27aqeKCs PnS7HjqweHpiJJRhq9Ps0npqoPiuQBoZQWWgvRvNc51fuuNAhhmfUbbkgtLxlK2lTJFw mBhmfBKJGGoNR9/C1bsCqX1ojTXcZIOsicT1msnuuvFxXLC6IH+eKHv0jQQbr0Oy4Kml wMXNLWpWSx+FSSziYqp1ES5YJY3YEZ9UAY/T2kREPpK7+awfdvM7l324bDNVHY1zFCVC r7Lrm7aSB3kyIjLk2iDWoNLNtnHhZRRwTenYYIpNlqLinsNQRDN0yjHQ5RPTpm05XSQ/ OJvg== X-Gm-Message-State: AOAM5310W/rJKfRbWdQlMNvPheURctjrUpYy//mW3/J6Wr/I6GAf0bdN 4E4Ff1+/ElelITsDgveHYXI9gtEXTbjQFc1ydPZTbA== X-Received: by 2002:a9d:186:: with SMTP id e6mr12528017ote.33.1591997532855; Fri, 12 Jun 2020 14:32:12 -0700 (PDT) MIME-Version: 1.0 References: <279f7f6606ea18e14d64517840bcada56deb0ce3.1583332765.git.vpillai@digitalocean.com> <20200612132127.GA90012@google.com> In-Reply-To: <20200612132127.GA90012@google.com> From: Vineeth Remanan Pillai Date: Fri, 12 Jun 2020 17:32:01 -0400 Message-ID: Subject: Re: [RFC PATCH 11/13] sched: migration changes for core scheduling To: Joel Fernandes Cc: Nishanth Aravamudan , Julien Desfossez , Peter Zijlstra , Tim Chen , Ingo Molnar , Thomas Gleixner , Paul Turner , Linus Torvalds , Aubrey Li , Linux List Kernel Mailing , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , Kees Cook , Greg Kerr , Phil Auld , Aaron Lu , Aubrey Li , "Li, Aubrey" , Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 12, 2020 at 9:21 AM Joel Fernandes wrote: > > > +#ifdef CONFIG_SCHED_CORE > > + if (available_idle_cpu(cpu) && > > + sched_core_cookie_match(cpu_rq(cpu), p)) > > + break; > > +#else > > select_idle_cpu() is called only if no idle core could be found in the LLC by > select_idle_core(). > > So, would it be better here to just do the cookie equality check directly > instead of calling the sched_core_cookie_match() helper? More so, because > select_idle_sibling() is a fastpath. > Agree, this makes sense to me. > AFAIR, that's what v4 did: > > if (available_idle_cpu(cpu)) > #ifdef CONFIG_SCHED_CORE > if (sched_core_enabled(cpu_rq(cpu)) && > (p->core_cookie == cpu_rq(cpu)->core->core_cookie)) > break; > #else > break; > #endif > This patch was initially not in v4 and this is a merging of 4 patches suggested post-v4. During the initial round, code was like above. But since there looked like a code duplication in the different migration paths, it was consolidated into sched_core_cookie_match() and it caused this extra logic to this specific code path. As you mentioned, I also feel we do not need to check for core idleness in this path. Thanks, Vineeth