Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp123708ybx; Wed, 6 Nov 2019 14:16:24 -0800 (PST) X-Google-Smtp-Source: APXvYqxZrF4YioobzsjfJJNl0lac7xkv+KZitKyzAxWt1jvFfcMI3ejldZWLVzSiAMcpYWGw2elx X-Received: by 2002:a50:8f03:: with SMTP id 3mr35236edy.195.1573078584805; Wed, 06 Nov 2019 14:16:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573078584; cv=none; d=google.com; s=arc-20160816; b=pr4Njw9T/Ypls17iTavpjZH8lH1IhSw/tzu3AsVybsgtXacWmoVNOEN6IdHyGR1Lm3 TBXEoaJe2BCslH662HMHykyMqDADo324HrdfJsKgvlBj5z7bD5ffjl4URmfTWGqgcvIW u8cDwT5gxGAI9zgJTTj8SxF4yL02du/3kuID0E/h9C+kA806WOCO0PL0ZHS+dbpJ1C/3 5grL+Ey2xFGBEP7lOpQWnhrj0l1vQCqrK2wq6vjwW9HjWUQcVbaxhCiZ5kdbzPJKuMQY 9AWyzqppB0v/HOcq3sDcgt5n+xOWld5l+iwP7BX94WHWLx7d73ABGtuTaCSbxWK+xN8C 6wNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:dkim-signature; bh=IPMIOrfkbztQvBBjOpcxydJjIPwlGr0+tNILSWIQfrc=; b=oQyplMal5lUh2XoCPbw7u+yuHjJqF5k0YNjYLe73mDe99pR6bctp7MXubYLkhC3RgA 99/Yw8dYOI8nK/XYTpD4afU+6LHADNzr6ibgF2o3OJFIPRS6I6DehiVPd4gIj1koTqC9 U0iit+jJv8NGkLB3AHjDG+kQu5s2ih1vyjkug8TcNAiHTCiBFRyoFUCsvlA0610M6CtB jD9PShF3xiClD+H66QiKYxIkNHp3RTE9sy+LlDKIw5TxGQsybAZeDYuRQ/mZa7fnn2ie 2TBv3BZbxSusSAtDvxVh0tt7/KLuE8gvt01BYl2JS6HPeMKo18a7YPGZJfM560+V+JIj 2B3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=T6Kn+zOq; 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 d20si128915ejk.173.2019.11.06.14.16.00; Wed, 06 Nov 2019 14:16:24 -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=T6Kn+zOq; 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 S1727559AbfKFWOx (ORCPT + 99 others); Wed, 6 Nov 2019 17:14:53 -0500 Received: from mail-pf1-f202.google.com ([209.85.210.202]:53166 "EHLO mail-pf1-f202.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727023AbfKFWOx (ORCPT ); Wed, 6 Nov 2019 17:14:53 -0500 Received: by mail-pf1-f202.google.com with SMTP id 20so20124443pfp.19 for ; Wed, 06 Nov 2019 14:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=IPMIOrfkbztQvBBjOpcxydJjIPwlGr0+tNILSWIQfrc=; b=T6Kn+zOqyFKAHoVesTBAS24L/v9IdGIWkQVkED4AYTkcFW3RmKiYxAwmciiMVx+5AB jOQm+7/9naeXuNQRjJhU4bYF1BZMBeeXq8oNIoTm1L8+07qbZLd9ToitDDhUpOIetBV+ S99DKw9fOinea2fHm0oZrULs2LerEsQ7/BZvnFLm4QQDAkjVdW63+xdr+sZMVrQRnVfc tpYGFcQlI49SyeXTcAfXKhLKOQsQCs+bmK1imNsTkZjEY8UwctNU+NFs+XqCKCpng+SB LuPXfuEjAZ4W9cc8E+u+4GwhQQRFTc/Yk8wFbNql6LUw7G2nw/wwI0OAGNBSQLMpsnU+ 5PLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=IPMIOrfkbztQvBBjOpcxydJjIPwlGr0+tNILSWIQfrc=; b=QXbU2ZSPhLfmZsO5Sx63s9ieCLiqjm8ywtkmqu8lz8N4kTCAo+9ZP0odGn6s8/js5H 1y7hfaZSkM3+t8T/ghOwQIt/4lP/LFI2XBRcxln46n9vUf5g11+A/yiAV/hHITHk1Ahg WBjNnD3FFg24HKJOc/nyxm4aMt5Rt40nMogMrPIeos3XJayoWkBmCFCnA5N3XBREey/F mElk/EzLGpotR4TzoOjyLq76DGI+n0hXWDiEbqLLcPNfTBkN2R/qTRKoVGGUGRtR9s6N 2afZPJL+9YIaXNcP/SV35vnc/Gi8AToWkVTb/UjB+TX6nX9AJ0XgghVGW0pgp7HVm2Be bCXQ== X-Gm-Message-State: APjAAAURFpy1fKrhGsgHSl9mGpTGxnE1bniOfnW9DdjmHwLvllgjhbbd tjgri3aEcU/blOUqE6sbujHikdLkR0i9 X-Received: by 2002:a63:d0d:: with SMTP id c13mr217521pgl.138.1573078490828; Wed, 06 Nov 2019 14:14:50 -0800 (PST) Date: Wed, 6 Nov 2019 14:14:48 -0800 In-Reply-To: Message-Id: <20191106221448.225183-1-joshdon@google.com> Mime-Version: 1.0 References: X-Mailer: git-send-email 2.24.0.rc1.363.gb1bccd3e3d-goog Subject: [PATCH v2] sched/fair: Do not set skip buddy up the sched hierarchy From: Josh Don To: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org, Paul Turner , Josh Don 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 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 --- Changelog since v1: - As an optimization, skip clearing the skip buddy up the hierarchy - Due to the above, it makes sense to inline __clear_buddies_skip; while we're at it, inline the other __clear_buddies* functions as well. kernel/sched/fair.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 682a754ea3e1..dbac30e3cc08 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4010,7 +4010,7 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags) } } -static void __clear_buddies_last(struct sched_entity *se) +static inline void __clear_buddies_last(struct sched_entity *se) { for_each_sched_entity(se) { struct cfs_rq *cfs_rq = cfs_rq_of(se); @@ -4021,7 +4021,7 @@ static void __clear_buddies_last(struct sched_entity *se) } } -static void __clear_buddies_next(struct sched_entity *se) +static inline void __clear_buddies_next(struct sched_entity *se) { for_each_sched_entity(se) { struct cfs_rq *cfs_rq = cfs_rq_of(se); @@ -4032,15 +4032,12 @@ static void __clear_buddies_next(struct sched_entity *se) } } -static void __clear_buddies_skip(struct sched_entity *se) +static inline 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) @@ -4051,8 +4048,7 @@ static void clear_buddies(struct cfs_rq *cfs_rq, struct sched_entity *se) if (cfs_rq->next == se) __clear_buddies_next(se); - if (cfs_rq->skip == se) - __clear_buddies_skip(se); + __clear_buddies_skip(se); } static __always_inline void return_cfs_rq_runtime(struct cfs_rq *cfs_rq); @@ -6647,8 +6643,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.rc1.363.gb1bccd3e3d-goog