Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp715988pxb; Fri, 14 Jan 2022 14:51:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJwzNYbbMTvuB7NXv/P6dY7KVSsEFUrs9YMW1E2bXniaBMkemh89jwG0W0klegpfeJUKHW9s X-Received: by 2002:a17:906:8557:: with SMTP id h23mr7417526ejy.451.1642200677346; Fri, 14 Jan 2022 14:51:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642200677; cv=none; d=google.com; s=arc-20160816; b=j4yQQdPyGfVYPdxiHkE0S+mnJiQdkOrod0Z/qiPKpQoUeU0Sg653Rzf6ZExdk/YVFH XQFbnfdPGipnfwRSwbTBnKQ8t3g6z1JAWMTMgK+vJlvNo7MXL4lL7wRIKN9o855Lp5Nf rD2Eiivu/MTfqW4x+xf+tloVuFQMleJmcAIV3qF+YLHmObNOhNrV8xoACjn61g3/ObpX kZg+dokYeyv7QGKSq9uRgHH3X7iOpprVEnva/69IXKZGO1r4wWaoi4uuHv9DOYJHpW+s cXDCotHDc50dVCHLSv4ayoXcCGsVngWDRYj1ArfpdVveevbGJfIwyVlVO+fUjFg/JTC0 JsHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=UdAhn1yP8utSK2rJWKDnZNaAaZ8ZXIqz54JjwpJvgpQ=; b=vehNz+VSS2jFRApFZEhA+P1+4zW83N5/hN/Ydqq0R20qDv8TmrgJcmhKzhts9y9q+J kNRYaETlcWsqD9T7GoOn7VPzlSGV9Jbk9ChVc762JVPWAHwTZQYdUZ8k/VEEFWA5FmJi hVH7EMu23jmhifLUmYr4ZgvM7NkdPZMhkszLGEIFFsLDgkFHtp/WcDiJsrxwvXBw8BS8 qsBnph/Sm3Qg7nh6NyvRNVHy8oKcdaFjqajOSwMhmTmzGVhrmB27BTn6H3MrT4cbwApv XV5q/cfIeT6dMm/Idyb4eJYCUG9Q4O5P6B5b02Hu0RZfvbVOBbG1G6GDjBP+TsKs7Pdj W7SA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=FQVcQ0Ac; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gb22si3442601ejc.332.2022.01.14.14.50.53; Fri, 14 Jan 2022 14:51:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-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=20210112 header.b=FQVcQ0Ac; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231806AbiANQiM (ORCPT + 99 others); Fri, 14 Jan 2022 11:38:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235179AbiANQiM (ORCPT ); Fri, 14 Jan 2022 11:38:12 -0500 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75500C061574; Fri, 14 Jan 2022 08:38:11 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id m21so3204980pfd.3; Fri, 14 Jan 2022 08:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UdAhn1yP8utSK2rJWKDnZNaAaZ8ZXIqz54JjwpJvgpQ=; b=FQVcQ0AcdShPy4qgO3i9uPzOtqze3SVxLhUjkznY3+NjqH5zxeeYYcdHlyORH7YzCJ eaeps+kM4+knX1Tt+p6X+l2Z1osOl+3/oB4Asy3CDb+L/uQjrplvtjr6Or1cmFQ3oMZW +mKI3MVFc3Y4lWRTRk+6hwx03WI4CGPgfjOsWGMMtmzJcFLixgCcJIwY9tIg9PgfhgKz iCm4pDLp9JT59E3Vz1FUfKGDOaj2HF+NOVuIZUQaVBoVd4ZOn9YAowHCHFmw8k7eTZ72 WU/1o6ohDldo/9Dkzqpq2N6wnpSPDqxBWELYegHy6Sm3yvg234/ckkpMlNEfbF7RX66D VC8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=UdAhn1yP8utSK2rJWKDnZNaAaZ8ZXIqz54JjwpJvgpQ=; b=ndbtu2K/gkpWRkp7aXTOqJs+njwSq7Xjxm8NYVwXOLLrX+EJ0oA7fWfitFH0P70fqe MJncsXL3w5NznOhzHYNL8Ov3strVfEfmsuk1BXOtnQGUn1u6XB/Inq9EGMFV6+q2atLj LIaA8g5dxMsR0L5cYkXOL8Yd/lrwtAlwbVICr/Q/ahw4AKn3dJZMWnF/S+bPKzwQX9s4 mmvwtmQVv3OGTqP3Elw6shDCzB+eKpOuKBeCgZp5PbwG1SDeEX1zE0zub3ZOf8I1LPlF ejpa3RZYTSE9PjMRiQ/LTw6lZxV+LiMkKED7ncuT83QFAib6+sIUn5b45BBLt8ltqjIg B1Cg== X-Gm-Message-State: AOAM533jJSgUrwHybEjLW/uPCoNyY9PTQmGZBTVBOmlaPcdxTtrBc/2E c7wo9gDGBBM1XiYqVRAUVJI= X-Received: by 2002:a65:6ab3:: with SMTP id x19mr8588083pgu.416.1642178290941; Fri, 14 Jan 2022 08:38:10 -0800 (PST) Received: from localhost (2603-800c-1a02-1bae-e24f-43ff-fee6-449f.res6.spectrum.com. [2603:800c:1a02:1bae:e24f:43ff:fee6:449f]) by smtp.gmail.com with ESMTPSA id w64sm636354pfd.0.2022.01.14.08.38.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Jan 2022 08:38:10 -0800 (PST) Sender: Tejun Heo Date: Fri, 14 Jan 2022 06:38:09 -1000 From: Tejun Heo To: Peter Zijlstra Cc: Daniel Jordan , Alexander Duyck , Alex Williamson , Andrew Morton , Ben Segall , Cornelia Huck , Dan Williams , Dave Hansen , Dietmar Eggemann , Herbert Xu , Ingo Molnar , Jason Gunthorpe , Johannes Weiner , Josh Triplett , Michal Hocko , Nico Pache , Pasha Tatashin , Steffen Klassert , Steve Sistare , Tim Chen , Vincent Guittot , linux-mm@kvack.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org Subject: Re: [RFC 15/16] sched/fair: Account kthread runtime debt for CFS bandwidth Message-ID: References: <20220106004656.126790-1-daniel.m.jordan@oracle.com> <20220106004656.126790-16-daniel.m.jordan@oracle.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-crypto@vger.kernel.org Hello, On Fri, Jan 14, 2022 at 10:40:06AM +0100, Peter Zijlstra wrote: > You could do a special case sched_move_task(), that takes a css argument > instead of using the current task_css. Then for cgroups it looks like > nothing changes, but the scheduler will DTRT and act like it is in the > target cgroup. Then at the end, simply move it back to task_css. > > This obviously doesn't work for SoftIRQ accounting, but that is > 'special' anyway. Softirq stuff is not otherwise under scheduler > control and has preemption disabled. So, if this particular use case doesn't fit the backcharge model (I'm not sure yet). I'd much prefer it to maintain dynamic per-cgroup helper threads than move tasks around dynamically. Nothing else is using migration this way and we don't even need migration for seeding cgroups w/ CLONE_INTO_CGROUP. In the future, this should allow further optimizations and likely simplifications. It'd suck to have an odd exception usage. Thanks. -- tejun