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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E05EC43217 for ; Wed, 2 Nov 2022 17:18:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231225AbiKBRSv (ORCPT ); Wed, 2 Nov 2022 13:18:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230241AbiKBRSq (ORCPT ); Wed, 2 Nov 2022 13:18:46 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07AC621E0A for ; Wed, 2 Nov 2022 10:18:46 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id l6so16902171pjj.0 for ; Wed, 02 Nov 2022 10:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=snrHQ66Kapq/ZWiiSBrIoHl05h2OD4hJ55ZZgf0M290=; b=nxOwtdWEzd0ZVsgHhCASXj/ZAxcC+rK4cIv4IMDVx886VIpjGAikdUD7TwXgymSora 2MEm/0hqDGWIjbLH26DUhPXp9USeqBt6D1duL+lhxHZDyU/G32ZnK4Cr4wl7IfTpNIiV m+fMXhgPR3IwLSwep21EqCj48erUiZINoDk5WziPmuJWqTxRc0Tk+QG4FQFLR+oITW8s SQoL5M9ciCvzLtLlPf31MdUoWc49cO8dPPmgs91kMGmjk9gJA0+QL60KK//QP+L6R7Qe R2jruRBaAgToAD39PRJq17AAi8WQ+II1fjPpk6l0kIcEuejUWqM5jFipk6lhSt5uyVqG Zd/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=snrHQ66Kapq/ZWiiSBrIoHl05h2OD4hJ55ZZgf0M290=; b=GSAWL0t3ifoUv69oOwDuukJVYCzDsDRqtI97xxw4cmchrYmkfY97uTpTpCLujbtxTv uJ0ebIEgh0hQCySJ/YWW7gc3Pz8aHOwR/ZXs+i3rhqydeIWoBXGp4EI9ae2H955h+Vd1 pI0HIo9HA4z/l2UFNfSWayY85w9r9F1L2HypV0p+rcw0SHGF6C6eVcABo1byJoSgL6ck INXk/yMYUEM3dOzMgYKCzr2ii7HTYa5nx0xvWHL2k51t7eitLCqqyRuj9imM3iDT/JJX oqu4ICYF8CUmffvdzMjQwIP9wx3i4BcsppS7i7CMhoyE9W9rr4201bXJDNP6lbZ2Xd5r r0Bg== X-Gm-Message-State: ACrzQf3ROZBNNzECaUoXuAfD8/4Hlwj4r03SX5ZeC1Yv/+c+CE9CsQwI +CKujc5N8lCs5gEG60jze8c= X-Google-Smtp-Source: AMsMyM5pP4O5S6/QQUpy9FbQmUmxGsyTjwI4l8J3sd3dd3CMfbpipCnSQTrPaLIBe95oktz+qPoBZg== X-Received: by 2002:a17:90a:c782:b0:202:c73e:5488 with SMTP id gn2-20020a17090ac78200b00202c73e5488mr43300957pjb.202.1667409525308; Wed, 02 Nov 2022 10:18:45 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-a7fa-157f-969a-4cde.res6.spectrum.com. [2603:800c:1a02:1bae:a7fa:157f:969a:4cde]) by smtp.gmail.com with ESMTPSA id n126-20020a622784000000b00562ef28aac6sm8672246pfn.185.2022.11.02.10.18.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 10:18:44 -0700 (PDT) Sender: Tejun Heo Date: Wed, 2 Nov 2022 07:18:43 -1000 From: Tejun Heo To: Michal =?iso-8859-1?Q?Koutn=FD?= Cc: Josh Don , Peter Zijlstra , 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, Joel Fernandes , Christian Brauner , Zefan Li Subject: Re: [PATCH v2] sched: async unthrottling for cfs bandwidth Message-ID: References: <20221102171049.GC10591@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221102171049.GC10591@blackbody.suse.cz> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 02, 2022 at 06:10:49PM +0100, Michal Koutný wrote: > On Tue, Nov 01, 2022 at 12:38:23PM -1000, Tejun Heo wrote: > > > We're in the process of transitioning to using bw instead for this > > > instead in order to maintain parallelism. Fixing bw is definitely > > > going to be useful, but I'm afraid we'll still likely have some issues > > > from low throughput for non-bw reasons (some of which we can't > > > directly control, since arbitrary jobs can spin up and configure their > > > hierarchy/threads in antagonistic ways, in effect pushing out the > > > latency of some of their threads). > > > > Yeah, thanks for the explanation. Making the lock more granular is tedious > > but definitely doable. I don't think I can work on it in the near future but > > will keep it on mind. If anyone's interested in attacking it, please be my > > guest. > > From my experience, throttling while holding kernel locks (not just > cgroup_mutex) causes more trouble than plain cgroup_mutex scalability > currently. Oh yeah, absolutely. Low cpu bw config + any shared kernel resource is a nightmare and this thread was originally about addressing that. Thanks. -- tejun