linux-kernel - Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YE/zvLkL1vM8/Cdm@slm.duckdns.org>
Date:   Mon, 15 Mar 2021 19:54:36 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Jacob Pan <jacob.jun.pan@...el.com>
Cc:     Vipin Sharma <vipinsh@...gle.com>, mkoutny@...e.com,
        rdunlap@...radead.org, thomas.lendacky@....com,
        brijesh.singh@....com, jon.grimm@....com, eric.vantassell@....com,
        pbonzini@...hat.com, hannes@...xchg.org, frankja@...ux.ibm.com,
        borntraeger@...ibm.com, corbet@....net, seanjc@...gle.com,
        vkuznets@...hat.com, wanpengli@...cent.com, jmattson@...gle.com,
        joro@...tes.org, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, hpa@...or.com, gingell@...gle.com,
        rientjes@...gle.com, dionnaglaze@...gle.com, kvm@...r.kernel.org,
        x86@...nel.org, cgroups@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, "Tian, Kevin" <kevin.tian@...el.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        "jean-philippe@...aro.org" <jean-philippe@...aro.org>
Subject: Re: [RFC v2 2/2] cgroup: sev: Miscellaneous cgroup documentation.

Hello,

On Mon, Mar 15, 2021 at 04:40:12PM -0700, Jacob Pan wrote:
> 2. then we want to move/migrate Process1 to cg_B. so we need uncharge 10 of
> cg_A, charge 10 of cg_B

So, what I don't get is why this migration is necessary. This isn't
supported as a usage pattern and no one, at least in terms of wide-spread
usage, does this. Why is this a requirement for your use case?

Thanks.

-- 
tejun