From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BEC88C2B9F4 for ; Fri, 25 Jun 2021 08:09:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A272C613F3 for ; Fri, 25 Jun 2021 08:09:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229949AbhFYILu (ORCPT ); Fri, 25 Jun 2021 04:11:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229748AbhFYILt (ORCPT ); Fri, 25 Jun 2021 04:11:49 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B5B5C061574 for ; Fri, 25 Jun 2021 01:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Pk4JdYaTmkcafJVH7LMc/B00NbQ927vWeJUlkQ+x8rI=; b=lvoXyscItXa1rIH1Cf3JU882AC 04AMKH8huNJHIbnEEIRC20vxvowkTNgcru1F17YQHjklc5l6e8K19Mo2+cBEwJhbhTvgxXQYxhwqq b/y4+gpq732HHhk/S4/ZFVNZr9363cOUF1xiMS1TgtLZ39JveB/xRFrQh1LtTbgiggiiGzRFUjd8G krLxEfrFbEor/PvXy2vFGKXUwu+cXngZ5iZuBJX1K6y4Ktyl+c7dlbh5LDf8E2WPyFQlaUE3CdWwA B1ZFWdrCXM92nk5lV1R955ufsJ8PRA6XRQrvJUHpn7kwWgAzR+zSei43lIgFeruNY1mHKi+BhjGPR spJfDPdg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwgtD-00HRl9-5x; Fri, 25 Jun 2021 08:08:43 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 3AFC030022B; Fri, 25 Jun 2021 10:08:36 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 1E1772B64C055; Fri, 25 Jun 2021 10:08:36 +0200 (CEST) Date: Fri, 25 Jun 2021 10:08:36 +0200 From: Peter Zijlstra To: Tejun Heo Cc: Josh Don , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Paul Turner , David Rientjes , Oleg Rombakh , Viresh Kumar , Steve Sistare , linux-kernel@vger.kernel.org, Rik van Riel Subject: Re: [PATCH] sched: cgroup SCHED_IDLE support Message-ID: References: <20210608231132.32012-1-joshdon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 16, 2021 at 11:42:05AM -0400, Tejun Heo wrote: > A high-level problem that I see with the proposal is that this would bake > the current recursive implementation into the interface. The semantics of > the currently exposed interface, at least the weight based part, is abstract > and doesn't necessarily dictate how the scheduling is actually performed. > Adding this would mean that we're now codifying the current behavior of > fully nested scheduling into the interface. It's a direct concequence of the hierarchical requirement. The approach is the only valid one. The other relative controllers that don't do this, are simply broken. Absolute controllers have it easier, they can be trivially flattened. > There are several practical challenges with the current implementation > caused by the full nesting - e.g. nesting levels are expensive for context > switch heavy applicaitons often going over >1% per level, Yeah, and there's numerical problems you run into as well due to limitied precision. Just don't do deep hierarchies. AFAICT it's a simple matter of conflicting requirements, on the one hand the hierarchical thing is required, on the other hand people seem to think all this crap is 'free' and create super deep hierarchies and then complain shit don't work right.