linux-kernel - Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

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]

Date:   Fri, 9 Sep 2016 14:43:25 -0700
From:   Shaohua Li <shli@...com>
To:     "Luck, Tony" <tony.luck@...el.com>
CC:     "Yu, Fenghua" <fenghua.yu@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Anvin, H Peter" <h.peter.anvin@...el.com>,
        Ingo Molnar <mingo@...e.hu>,
        Peter Zijlstra <peterz@...radead.org>,
        Tejun Heo <tj@...nel.org>, Borislav Petkov <bp@...e.de>,
        Stephane Eranian <eranian@...gle.com>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        "David Carrillo-Cisneros" <davidcc@...gle.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
        "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel
 resource allocation user interface

On Fri, Sep 09, 2016 at 06:03:12PM +0000, Luck, Tony wrote:
> > I don't think this is convenient, but it's ok. Now if we create a new thread
> > between 1 and 2, the new thread is in group1. The new thread pid isn't in the
> > pid list we found in 1, so after 2, the new thread still is in group 1. Truely
> > sysadmin can repeat the step 1 & 2 and move the new thread to group 2, but
> > there is always chance the process creates new thread between 1 and 2, and the
> > new thread remains in group 1. There is no guarantee we can safely move a
> > process from one group to another.
> 
> In general this is true.  But don't most threaded applications have a single thread that
> is the one that spawns new threads? Typically the first thread.  Once that is moved,
> any new threads will inherit the new group. So there won't be a neverending mopping
> operation trying to catch up.
> 
> Even this seems outside the expected usage model for CAT where we expect the
> system admin to partition the cache between resource groups at boot time and
> then assign jobs (or containers, or VMs) to resource groups when they are created.

Hmm, I don't know how applications are going to use the interface. Nobody knows
it right now. But we do have some candicate workloads which want to configure
the cache partition at runtime, so it's not just a boot time stuff. I'm
wondering why we have such limitation. The framework is there, it's quite easy
to implement process move in kernel but fairly hard to get it right in
userspace.

Thanks,
Shaohua