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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 99F57C4361B for ; Wed, 16 Dec 2020 20:04:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A30120639 for ; Wed, 16 Dec 2020 20:04:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728707AbgLPUDh (ORCPT ); Wed, 16 Dec 2020 15:03:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728689AbgLPUDh (ORCPT ); Wed, 16 Dec 2020 15:03:37 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AEAE7C0617A6 for ; Wed, 16 Dec 2020 12:02:56 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id m12so51539304lfo.7 for ; Wed, 16 Dec 2020 12:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+T1M0djTrVYMWMJ7UcJwx0tkQ79zd8SuUMW71DQVsS0=; b=q+DyxhaxnPb/nH8qJzxHDRUDbs6pwrBVZw6PzpLeFo3wtldBNCEn4e64bSK0nhLF5X QvBT/wceHb8MK7Fm6YtVe7alN3zuwE0T3jaFFX9VRfhZKifVX3CDGzSjGXXVAJJpXSLk BYqUA0lzyEkYCfA/0WuODCJH5mOGW4V8P0cbCJlM2NdsPkwY5ZpUVEVBumz8vq3xmZQm PQyEwimqMI9kswHp6aDK7UXpsBu5joatambFWqpECUHqscsjIaEKpGZiYFMen0Kf3XVW Q8YKf8+FVjWvyXB/rJ0RfDFFi19z72HtGBVwOT5yFzE5kLAsEpDIgG2ZzYj5KaG1wkfA IjGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+T1M0djTrVYMWMJ7UcJwx0tkQ79zd8SuUMW71DQVsS0=; b=iEeAeAl7Oza25VwhA3Rhli2/i9IhKnhXtfDJsvavbnT8d1qVJZw/KqEaDpt/VY/xUc gtgprzlzvvNHa4BksDDvOHRgw8KdzT24/DalgZoG5S0umLD/S+xb/eW82p9Ht32X1x9h WJaI90FKH0hUaiFsAMRKNxzpL+GUJ/AiyioTwHYTiZdRDEuWHnHiTxzHKtr2euwMmR4v V59dIQWXc7L7BPZncOGdHkq252paS80MnkWrzsvink7YOIzYYtmhEKgOSqMxhDECKaNJ BC3EnKSTyFgUuidXmDwtKiStfxszgOUVErEcfxqlbDx3u6zWqX/TTluywWp4PGOOMQOS QDeQ== X-Gm-Message-State: AOAM530NAsrlMvocRKBr/Js4NNbNgaGc1QFL5zsbbXo3yk+2d/gEo4cc CusFMIm2G23AklzVgXhlHX0amCumMtyzEP99IYf3QA== X-Google-Smtp-Source: ABdhPJwIsp1KYDGfDYl/qLLsUR1dFSzUtaS6n+MO1KkOUvZ4UrkSMNj8fmCA+zqoeFpXCBoAmALBMZNzzSZUYt5+MhQ= X-Received: by 2002:a19:4813:: with SMTP id v19mr14625283lfa.655.1608148974571; Wed, 16 Dec 2020 12:02:54 -0800 (PST) MIME-Version: 1.0 References: <20201209205413.3391139-1-vipinsh@google.com> <4f7b9c3f-200e-6127-1d94-91dd9c917921@de.ibm.com> <5f8d4cba-d3f-61c2-f97-fdb338fec9b8@google.com> In-Reply-To: From: Vipin Sharma Date: Wed, 16 Dec 2020 12:02:37 -0800 Message-ID: Subject: Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller To: Tejun Heo Cc: David Rientjes , Christian Borntraeger , Tom Lendacky , Brijesh , Jon , Eric , pbonzini@redhat.com, Sean Christopherson , lizefan@huawei.com, hannes@cmpxchg.org, Janosch Frank , corbet@lwn.net, joro@8bytes.org, vkuznets@redhat.com, wanpengli@tencent.com, Jim Mattson , tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, Matt Gingell , Dionna Glaze , kvm@vger.kernel.org, x86@kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 9, 2020 at 12:59 PM Tejun Heo wrote: > * I don't have an overall objection. In terms of behavior, the only thing > which stood out was input rejection depending on the current usage. The > preferred way of handling that is rejecting future allocations rather than > failing configuration as that makes it impossible e.g. to lower limit and > drain existing usages from outside the container. Thanks. In next version of the patch I will remove rejection of max value based on current usage. On Wed, Dec 16, 2020 at 7:27 AM Tejun Heo wrote: > On Thu, Dec 10, 2020 at 03:44:35PM -0800, David Rientjes wrote: > > Concern with a single misc controller would be that any subsystem that > > wants to use it has to exactly fit this support: current, max, stat, > > nothing more. The moment a controller needs some additional support, and > > its controller is already implemented in previous kernel versionv as a > > part of "misc," we face a problem. > > Yeah, that's a valid concern, but given the history, there doesn't seem to > be much need beyond that for these use cases and the limited need seems > inherent to the way the resources are defined and consumed. So yeah, it can > either way. I think a misc controller should be able support other "Resource Distribution Models" mentioned in the cgroup v2 documentation besides limits. There might be use cases in future which want to use weight, protection or allocation models. If that happens it will be more difficult to support these different resources. This will also mean the same hierarchy might get charged differently by the same controller. I like the idea of having a separate controller to keep the code simple and easier for maintenance. If you decide to have a separate misc controller please let me know what will be the overall expectations and I can change my patch to reflect that, otherwise I can send out a new patch with just removal of max input rejection. My understanding with a "misc" controller is it will be something like - cgroup v2 cgroup/misc.encryption_ids.{sev, tdx, seid}.{stat, max, current} - cgroup v1 cgroup/misc/misc.encryption_ids.{sev, tdx, seid}.{stat, max, current} Thanks Vipin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vipin Sharma Subject: Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller Date: Wed, 16 Dec 2020 12:02:37 -0800 Message-ID: References: <20201209205413.3391139-1-vipinsh@google.com> <4f7b9c3f-200e-6127-1d94-91dd9c917921@de.ibm.com> <5f8d4cba-d3f-61c2-f97-fdb338fec9b8@google.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+T1M0djTrVYMWMJ7UcJwx0tkQ79zd8SuUMW71DQVsS0=; b=q+DyxhaxnPb/nH8qJzxHDRUDbs6pwrBVZw6PzpLeFo3wtldBNCEn4e64bSK0nhLF5X QvBT/wceHb8MK7Fm6YtVe7alN3zuwE0T3jaFFX9VRfhZKifVX3CDGzSjGXXVAJJpXSLk BYqUA0lzyEkYCfA/0WuODCJH5mOGW4V8P0cbCJlM2NdsPkwY5ZpUVEVBumz8vq3xmZQm PQyEwimqMI9kswHp6aDK7UXpsBu5joatambFWqpECUHqscsjIaEKpGZiYFMen0Kf3XVW Q8YKf8+FVjWvyXB/rJ0RfDFFi19z72HtGBVwOT5yFzE5kLAsEpDIgG2ZzYj5KaG1wkfA IjGQ== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tejun Heo Cc: David Rientjes , Christian Borntraeger , Tom Lendacky , Brijesh , Jon , Eric , pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Sean Christopherson , lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, Janosch Frank , corbet-T1hC0tSOHrs@public.gmane.org, joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org, vkuznets-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, wanpengli-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org, Jim Mattson , tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org, hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, Matt Gingell , Dionna Glaze , kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Wed, Dec 9, 2020 at 12:59 PM Tejun Heo wrote: > * I don't have an overall objection. In terms of behavior, the only thing > which stood out was input rejection depending on the current usage. The > preferred way of handling that is rejecting future allocations rather than > failing configuration as that makes it impossible e.g. to lower limit and > drain existing usages from outside the container. Thanks. In next version of the patch I will remove rejection of max value based on current usage. On Wed, Dec 16, 2020 at 7:27 AM Tejun Heo wrote: > On Thu, Dec 10, 2020 at 03:44:35PM -0800, David Rientjes wrote: > > Concern with a single misc controller would be that any subsystem that > > wants to use it has to exactly fit this support: current, max, stat, > > nothing more. The moment a controller needs some additional support, and > > its controller is already implemented in previous kernel versionv as a > > part of "misc," we face a problem. > > Yeah, that's a valid concern, but given the history, there doesn't seem to > be much need beyond that for these use cases and the limited need seems > inherent to the way the resources are defined and consumed. So yeah, it can > either way. I think a misc controller should be able support other "Resource Distribution Models" mentioned in the cgroup v2 documentation besides limits. There might be use cases in future which want to use weight, protection or allocation models. If that happens it will be more difficult to support these different resources. This will also mean the same hierarchy might get charged differently by the same controller. I like the idea of having a separate controller to keep the code simple and easier for maintenance. If you decide to have a separate misc controller please let me know what will be the overall expectations and I can change my patch to reflect that, otherwise I can send out a new patch with just removal of max input rejection. My understanding with a "misc" controller is it will be something like - cgroup v2 cgroup/misc.encryption_ids.{sev, tdx, seid}.{stat, max, current} - cgroup v1 cgroup/misc/misc.encryption_ids.{sev, tdx, seid}.{stat, max, current} Thanks Vipin