Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1263149ybl; Fri, 6 Dec 2019 14:14:11 -0800 (PST) X-Google-Smtp-Source: APXvYqy1ZRVEbhQnPbuSHXoS7QCv+7d6mpk/2OqevIFcao3jqKV6YaT96m6sReMKVtwgHr3DsiC+ X-Received: by 2002:a05:6830:1042:: with SMTP id b2mr12962172otp.306.1575670451674; Fri, 06 Dec 2019 14:14:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575670451; cv=none; d=google.com; s=arc-20160816; b=sYIUvHHuYXTon7M1oPoSHVwGuoo+yKm7w2JhvbHK1uVgEfD+b2ZqaEqMSSy+fqsTUW RlOtdVyvK8r4peYZGmT4df7Um6wYuukfpW6x1j/jW9Fehqt5pBnsFzUDIPRFP24qfNxO P1ZsrvKKKATtngRy1Ts21M35n6GboVyh0XAfycGGOh+ABjTre2dX/HbBUSH4rydqL1Ly WbZDkGFw2QKzNZb7GUoYxNU5sdCvOxY7rIpw4PeVKOGxPklKwv6b2Xr80RVsmKZyL0Eo 4LN57XON8FeY5KGQ9yxHF3AFtqqtXinBWuWVJ3n/J3lLKfoDPRrmV7BeyyHsVcSx9KIy sDzA== 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=XWAFy/mhi8Rmp8q07EC5kiE1uUIRPU7vMiVGdCYXdOU=; b=usGFmGx2tP2+OR6VGnSzhMp7ZYF4xFFPm0EvDqdaFq/vJwqt71+uwBfiY+izuYXG2i NxKPqDMH0d1nmm/dfb3o+PTexNR82OJM0MXDX6qsXDJ4eT0OKOXeD61C2YjJeEJSLO8m ovh3PYsfjwYJqEVUSyVn+29KG7B85WLGojSfKYceruMnplXuQnJ5Leu+jeMtUtuSleVF wLt65KFzS+rTBzvUrWAEBqEpGG2P8EtSW9vKlSmySgqfUc2J2Lt4VbhUja+2n7BEg+T7 xCCjM9goAdMIEBt5n+feS92e+01TfloWgCEKX4VgN6VeNG+ECkwrg/AZLDVOlgkGWdkf CXvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IX6ZfmwL; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k67si3095522oib.61.2019.12.06.14.13.59; Fri, 06 Dec 2019 14:14:11 -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=@google.com header.s=20161025 header.b=IX6ZfmwL; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726421AbfLFWN2 (ORCPT + 99 others); Fri, 6 Dec 2019 17:13:28 -0500 Received: from mail-qk1-f194.google.com ([209.85.222.194]:36681 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726377AbfLFWN2 (ORCPT ); Fri, 6 Dec 2019 17:13:28 -0500 Received: by mail-qk1-f194.google.com with SMTP id s25so2883708qks.3 for ; Fri, 06 Dec 2019 14:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XWAFy/mhi8Rmp8q07EC5kiE1uUIRPU7vMiVGdCYXdOU=; b=IX6ZfmwLLMFWTPkNcUhH2lfYAiGeN5disemyiNXjVEyXD/gt87ZzdgUn8CmCrLnYCj fAhR+K/WNfxaLZGfmbUUifZYTE3Ch9PfqsAd4TBaEO/sCVjMN0il/rqO9f+exyAB7LYc fha0xsKJZkQ4qeijd7KWWjVslvyS7DlMnVpN+BpYiMFwW8qUzkLQpTsc7TXDMEtKIcms BdztEwYS1gfNMioRey0XM71bO7tw5D/v9cDPJBxStahN3He5BgiZpDhl9ZCamvHu/x8T UcMAst2iNFC91vkN4CTFOsTWxx9gFsRnZnTkyHIB7km+0B1sdV6+GOk+b7aKeAR7BY3q e0ZA== 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=XWAFy/mhi8Rmp8q07EC5kiE1uUIRPU7vMiVGdCYXdOU=; b=aEr8XsksmlDSFFSR9LrVgkyY4hgPOBx6jTIY0KmT4eo69AbX1eQnzvKNGQDHu4bVsi 0l9xXNDX0HQ5N0Wh6P4bI9rJm984oOCex07x84FvwUt9JJ0U8nCxVLz6eqkXiktb7H51 tB8doZ+UjbWnvk/5fTK5ibFuxdKoaImeo731RRfHiekh5OjTgrGDx+gFqe19QqcKGsQE 3Sb6oDmtM89JIrkddO70TwSS4dA15ao5mxluy90KYmZ3apm6vyKpqdl3RJZy9MccfX4q QEL3D7qtS2+hlwcGIu02Gohq1HiPMihDHra6whEzZpQvgUw98ArHIc6XwXEUWdcRIv/p AFlw== X-Gm-Message-State: APjAAAWBBks99GCWPv9uqhJbCdzbboyAlDYFv2aWABP+baiMEPKZ8f/q cGwOarf1EMsSlLxWurH3OrqG5SCQpdYBVq0fBU8Esw== X-Received: by 2002:ae9:efc5:: with SMTP id d188mr16436211qkg.178.1575670406741; Fri, 06 Dec 2019 14:13:26 -0800 (PST) MIME-Version: 1.0 References: <20191204200623.198897-1-joshdon@google.com> In-Reply-To: From: Josh Don Date: Fri, 6 Dec 2019 14:13:15 -0800 Message-ID: Subject: Re: [PATCH v2] sched/fair: Do not set skip buddy up the sched hierarchy To: Vincent Guittot Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , linux-kernel , Paul Turner 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 Hi Vincent, Thanks for taking a look. > There is a mismatch between the author Venkatesh Pallipadi and the > signoff Josh Don > If Venkatesh is the original author and you have then done some > modifications, your both signed-off should be there Venkatesh no longer works at Google, so I don't have a way to get in touch with him. Is my signed-off insufficient for this case? On Thu, Dec 5, 2019 at 11:57 PM Vincent Guittot wrote: > > Hi Josh, > > On Wed, 4 Dec 2019 at 21:06, Josh Don wrote: > > > > From: Venkatesh Pallipadi > > > > Setting skip buddy all the way up the hierarchy does not play well > > with intra-cgroup yield. One typical usecase of yield is when a > > thread in a cgroup wants to yield CPU to another thread within the > > same cgroup. For such a case, setting the skip buddy all the way up > > the hierarchy is counter-productive, as that results in CPU being > > yielded to a task in some other cgroup. > > > > So, limit the skip effect only to the task requesting it. > > > > Signed-off-by: Josh Don > > There is a mismatch between the author Venkatesh Pallipadi and the > signoff Josh Don > If Venkatesh is the original author and you have then done some > modifications, your both signed-off should be there > > Apart from that, the change makes sense to me > > > --- > > v2: Only clear skip buddy on the current cfs_rq > > > > kernel/sched/fair.c | 18 +++++++++++------- > > 1 file changed, 11 insertions(+), 7 deletions(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 08a233e97a01..0b7a1958ad52 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -4051,13 +4051,10 @@ static void __clear_buddies_next(struct sched_entity *se) > > > > static void __clear_buddies_skip(struct sched_entity *se) > > { > > - for_each_sched_entity(se) { > > - struct cfs_rq *cfs_rq = cfs_rq_of(se); > > - if (cfs_rq->skip != se) > > - break; > > + struct cfs_rq *cfs_rq = cfs_rq_of(se); > > > > + if (cfs_rq->skip == se) > > cfs_rq->skip = NULL; > > - } > > } > > > > static void clear_buddies(struct cfs_rq *cfs_rq, struct sched_entity *se) > > @@ -6552,8 +6549,15 @@ static void set_next_buddy(struct sched_entity *se) > > > > static void set_skip_buddy(struct sched_entity *se) > > { > > - for_each_sched_entity(se) > > - cfs_rq_of(se)->skip = se; > > + /* > > + * One typical usecase of yield is when a thread in a cgroup > > + * wants to yield CPU to another thread within the same cgroup. > > + * For such a case, setting the skip buddy all the way up the > > + * hierarchy is counter-productive, as that results in CPU being > > + * yielded to a task in some other cgroup. So, only set skip > > + * for the task requesting it. > > + */ > > + cfs_rq_of(se)->skip = se; > > } > > > > /* > > -- > > 2.24.0.393.g34dc348eaf-goog > >