Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1950025ybk; Thu, 21 May 2020 20:46:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxgTg0ZtRyeGvdUo8i4i2wPsPPtDKPPkme45DOXRnGm9YwBWqYGXNokOL9cEHp0767UtZj5 X-Received: by 2002:a17:907:4426:: with SMTP id mv6mr6744541ejb.440.1590119199969; Thu, 21 May 2020 20:46:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590119199; cv=none; d=google.com; s=arc-20160816; b=pIDN54qRbj8wCEd67pFq6oaSjWmfi7nF6GDIc4cLauvxgELqcHun8YVKpdFed21BXX 2+2lQqKi62EFH6gM3Ljz25YaW5I894NuAtWoWyAnRO7G5BUU1g2f4BClv0A9WIFFrzvP nqSYtA8SuMX9Nr2hM9wvkHsK+hk67H8Sn7gpEG/EPX7CtEh+vTXJdpVKF/K6PfKU2s5B nVwbn026MhF14EdZDXILcvQDyjrZ+gh849Spg1VbSPnUy2nYnmDDxAYJWrPT48k2Fy2L 4IThSgr4hm+lnsEsb8svSwW6FMh6ul6sAvyTCaiDetOAxMcXGgQogNqj2eudBwdqM/Y1 31+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=b9te6oLf3ZXULIfTnJCiCYesvc6Tdl5yFCs6fyx4feA=; b=odWlC4hR1Gut4BRVumaH2S2fxL/Ijc/uCLQ+46DzBfaZDWQyCuSKkacoaSST/znKQV OQAPM/Sm1nELlwMpzQwMVYDSbj/PvV0l9W5qE8oa+QeWnFnccBLvqA7aY4uWWE0LnVd1 MQRm99AGfmeX38mwPMbU0chjj5M4ofbTFSOkkmsdotEkbeYLo4Y9d9p4Zkpcx5NPQVfC Dxaeakgi8CwnbbP2CncSgzXNg4fkNxQOZHigi7954hk6mmvDA6j5M6HqU3wY485uQrDf OJTug/KS/d8zA9kd1/50nnUOzNAN4et3lMswhQWy1EPQEUvGGksW/lFmLEkjGfwEQ5xG vqCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EUoCzPiL; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k10si4055041edx.155.2020.05.21.20.46.17; Thu, 21 May 2020 20:46:39 -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=@gmail.com header.s=20161025 header.b=EUoCzPiL; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728175AbgEVDoP (ORCPT + 99 others); Thu, 21 May 2020 23:44:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727996AbgEVDoO (ORCPT ); Thu, 21 May 2020 23:44:14 -0400 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C4F4C061A0E for ; Thu, 21 May 2020 20:44:14 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id 145so4525682pfw.13 for ; Thu, 21 May 2020 20:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=b9te6oLf3ZXULIfTnJCiCYesvc6Tdl5yFCs6fyx4feA=; b=EUoCzPiL6zC+w8TzN+sGpX+tndIFp0FqCMLv7ajsny6RxzqLSWVrCPOdN/W5ov5m/B 4XAuCYCAkpXRWSTGVxGTpT+Hy5GKfo6XS0NYuAEpLkiG8HCZGbnYu2CWKrhh855y2aFs td4xnAliGHeAWA8iKp5/eclguorNNBRPgXgnTXtHesArM8ePNZK56LX8juJO7J1tLHrs vSzZJIOzm1KcmhXj79d+GP1sGiXvf21d85etyQ/l0jH8DFXk5rhCZcTuysWTSpgmgU81 hSDp3dgmXqAU6KMxc6OrJCANclWwS4WttCYvRIlZnVFvfOK8Sff2oRjhJcA7L4Dq08tU ZhUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=b9te6oLf3ZXULIfTnJCiCYesvc6Tdl5yFCs6fyx4feA=; b=HlGAYL6W2GkH5rhSFSfnNr6T3XAJcUnlKzLXM8UWIoSAF15d+e42i9b7cKmWo2nOB0 2axrlcxHxd9u6hT2nedg4/+ff8c7rffXKfzCFZ7XajkHNx38ztgGvJWVNSOlaGSbyVmo vzO77MU21k8lqmpeKGIL0DEmGADBxUfnz5A9cUgb5jmk72IrSxHO8fL/Rfk5USIdBZkT Mj2Adwh+3d9iR0Sj+11QKKS0bvnDUJcFPG64VQks44VPI82Y6OsV8NlGhbY+k2+ksk+5 5cWfByyxakdrBZ+5UCT9RT4HQpJL0VPyJAyp/fTA+GLWQtaV3Z05x745cygpK+yDsPZZ M/hw== X-Gm-Message-State: AOAM530rp4XXUvM1h0mnUBJMbTp/Y8a6orz6GaWm4fXkU2Bp8dZasaKT FQ1BMrN6L8/StRl+qsZhj24= X-Received: by 2002:aa7:9297:: with SMTP id j23mr1920708pfa.15.1590119054088; Thu, 21 May 2020 20:44:14 -0700 (PDT) Received: from aaronlu-desktop ([47.89.83.64]) by smtp.gmail.com with ESMTPSA id h17sm5692643pfr.25.2020.05.21.20.44.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2020 20:44:13 -0700 (PDT) Date: Fri, 22 May 2020 11:44:06 +0800 From: Aaron Lu To: Joel Fernandes Cc: vpillai , Nishanth Aravamudan , Julien Desfossez , Peter Zijlstra , Tim Chen , mingo@kernel.org, tglx@linutronix.de, pjt@google.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, fweisbec@gmail.com, keescook@chromium.org, kerrnel@google.com, Phil Auld , Aubrey Li , aubrey.li@linux.intel.com, Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini , Aaron Lu Subject: Re: [RFC PATCH 07/13] sched: Add core wide task selection and scheduling. Message-ID: <20200522034406.GC6339@aaronlu-desktop> References: <20200521231426.GA246288@google.com> <20200522023556.GE140701@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200522023556.GE140701@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 21, 2020 at 10:35:56PM -0400, Joel Fernandes wrote: > Discussed a lot with Vineeth. Below is an improved version of the pick_task() > similification. > > It also handles the following "bug" in the existing code as well that Vineeth > brought up in OSPM: Suppose 2 siblings of a core: rq 1 and rq 2. > > In priority order (high to low), say we have the tasks: > A - untagged (rq 1) > B - tagged (rq 2) > C - untagged (rq 2) > > Say, B and C are in the same scheduling class. > > When the pick_next_task() loop runs, it looks at rq 1 and max is A, A is > tenantively selected for rq 1. Then it looks at rq 2 and the class_pick is B. > But that's not compatible with A. So rq 2 gets forced idle. > > In reality, rq 2 could have run C instead of idle. The fix is to add C to the > tag tree as Peter suggested in OSPM. I like the idea of adding untagged task to the core tree. > Updated diff below: > > ---8<----------------------- > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 005d7f7323e2d..625377f393ed3 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -182,9 +182,6 @@ static void sched_core_enqueue(struct rq *rq, struct task_struct *p) > > rq->core->core_task_seq++; > > - if (!p->core_cookie) > - return; > - > node = &rq->core_tree.rb_node; > parent = *node; > > @@ -215,7 +212,7 @@ static void sched_core_dequeue(struct rq *rq, struct task_struct *p) > > void sched_core_add(struct rq *rq, struct task_struct *p) > { > - if (p->core_cookie && task_on_rq_queued(p)) > + if (task_on_rq_queued(p)) > sched_core_enqueue(rq, p); > } It appears there are other call sites of sched_core_enqueue() where core_cookie is checked: cpu_cgroup_fork() and __sched_write_tag().