Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6354063rwb; Tue, 22 Nov 2022 12:08:19 -0800 (PST) X-Google-Smtp-Source: AA0mqf6q5hwgJoslRpBa1KvdsCiIK2BwI3dQGIMtMoXuPu8usXhgmUKr3y57ZZwcgFQgnlEaBYEp X-Received: by 2002:a17:906:15ca:b0:7a5:7c1c:cc5c with SMTP id l10-20020a17090615ca00b007a57c1ccc5cmr21030145ejd.644.1669147699246; Tue, 22 Nov 2022 12:08:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669147699; cv=none; d=google.com; s=arc-20160816; b=whLUOg8H4W19ohXw/n0gWzjD4KnEQAeelzYmoqFtTrlnZc80KHFIb6v75kMMn5l78p m8Jz8KBF4Yy1CWJJv64I7UdoCPfwlpQ2bxz+Kjb5rol2+diicBXWaDkdeKo3+bM16NMq 9hyd5Y8Pon7pXCBvApkcE8njEtBvJig3w4pig11QWbAnjD4GWzPz8Xg8gAIyRspjZ8GT Z93rcvSvxkJfgtQ/b7twSBY3YS1zK6yS3vM26wRdZcbJfOhd0T/p0UtGBJ9LX7hTH+bj NuK18nIxijoepRp/UpAuhVq0MQRmGC+BXvjOdDNDImTjGxrGAVWRrO8kBRheIF6KTXuj LHvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=huY5awniuetQkBJOXy/Pee5GMfNTDh3mJcwr+bXp+Ig=; b=Dz2OQOFROFBv1CoDB4oF+dJIL8Syt9N1sK/vISghYVFIGaB3yuKuHpSofa934qbpTv Iqc29td1M85FJtxmdr/LZtFGG7y5ClwvZlSoiL9U3gE2OcXL/YYl7hvWbiozUYIhD5bp 4UAcYwaSJUUrdVUB5eRvYi0d00kx/eC25AMQXYPtBytJYo2MEzRjPDg7keamIghLKrkc z5tfQ8de2Ges0eh3l4rt7c26r+o8B/6DoxAPpPU6QdKFVmuxuKxWXAtJy0JChHxAXv/5 bwy+/AeMq4G+ZRU56gvNd7nofbm6BO/IBGnBHTx1ioOlEVNWwgfZKV8hnHXhNBq8C7fA DgVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=LPmVmfLh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ty13-20020a170907c70d00b007ae87dde2c7si10407420ejc.830.2022.11.22.12.07.56; Tue, 22 Nov 2022 12:08:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=LPmVmfLh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S234322AbiKVTlX (ORCPT + 90 others); Tue, 22 Nov 2022 14:41:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60616 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232685AbiKVTlT (ORCPT ); Tue, 22 Nov 2022 14:41:19 -0500 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51B756F372 for ; Tue, 22 Nov 2022 11:41:18 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id bp15so25048814lfb.13 for ; Tue, 22 Nov 2022 11:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=huY5awniuetQkBJOXy/Pee5GMfNTDh3mJcwr+bXp+Ig=; b=LPmVmfLhqIn4AbzQZEOyBt7rAY8obFeVGkTt2bTrzabJ0g8lJRilGYPCCd7kUN9Ey6 4TIjQJTZ12jvQvp66xIekrdcr5PsvfLsLQIqNpZrhwTvIz7I1vVmFtz20lQobSgbq28f iO3m+9K8KUIQw0Tw41mhrvi9RDgYO6//RlyyA342j9LCNhCEmtQiEm+zZnlwaqfLvdca 7kANZKE8x/ZR86W+3tHifaK2u94043GSaco9Za3Gj46FbgYVz6C07T48Fwk+BI+VMhHx g2WWlncLBI3/NR+oncWs3WdDUgnbWeA4Mn7pf9JJCS+tCmvKlMxBgUAb4fgzJpwau8xN 74Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=huY5awniuetQkBJOXy/Pee5GMfNTDh3mJcwr+bXp+Ig=; b=Qr/8ZQ4oOW9lBldpszFwM53VuDsHqSzNHREtIwYdkOymlK2GpfGyx/qdYJcoW50YyN 4vYUuK8awckL042PhXA4rEXaDAAwc6YxhRHrOuyhUo9L4kmESlW/YprEacFXEz87/KRh RDPSQ0NKhOY8tGwXHlEqtU/yc+FOMm8/UJ3eMzJdfDXUWIxg3x6qAASvcjoL5nUKHfv0 igQuipDuEbi1GJy8ajgPjSlLobk6nVa6uWtXC7E3VSpObUgQ+NKn8y7TpMYtXx9HWVQk LvRyGbEiCx0xenRSHpleC4yOVqz4bmg30aGP82RXt27SinhZInDibPX5+tOLnCriVden 1k+g== X-Gm-Message-State: ANoB5pmDwh0+4LD4eFpA2acu3cTHDoOaRdssA35g6UiqN+ExQjMLl/wp Vgi6Mb1zGzuyWFhnpQDvecpx4HdKDfSEEf0MLaiCYg== X-Received: by 2002:a19:7107:0:b0:4a8:e955:77e7 with SMTP id m7-20020a197107000000b004a8e95577e7mr2308741lfc.573.1669146076359; Tue, 22 Nov 2022 11:41:16 -0800 (PST) MIME-Version: 1.0 References: <20221117005418.3499691-1-joshdon@google.com> In-Reply-To: From: Josh Don Date: Tue, 22 Nov 2022 11:41:04 -0800 Message-ID: Subject: Re: [PATCH v3] sched: async unthrottling for cfs bandwidth To: Aaron Lu , Peter Zijlstra Cc: Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel@vger.kernel.org, Tejun Heo , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Christian Brauner , Zefan Li Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > + */ > > + if (local_unthrottle) { > > + rq = cpu_rq(this_cpu); > > + rq_lock_irqsave(rq, &rf); > > Should we add: > if (cfs_rq_throttled(local_unthrottle)) > > before calling into unthrottle_cfs_rq_async(local_unthrottle) to avoid a > potential WARN? > > As for whether the local cfs_rq can be unthrottled now after rq lock is > re-acquired, I suppose it can be. e.g. another user sets a new quota to > this task group during the window of rq lock gets dropped in the above > loop and re-acquired here IIUC. > > > + unthrottle_cfs_rq_async(local_unthrottle); > > + rq_unlock_irqrestore(rq, &rf); > > + } > > + > > return throttled; > > } Yes, we should add that check due to the case you described with a user concurrently configuring bandwidth. And as long as we're doing that, we might as well make this unthrottle_cfs_rq() instead and snip the comment. Peter, would you mind adding that delta?