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:   Sun, 11 Sep 2016 21:15:40 -0700
From:   Shaohua Li <shli@...com>
To:     "Yu, Fenghua" <fenghua.yu@...el.com>
CC:     "Luck, Tony" <tony.luck@...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 Sat, Sep 10, 2016 at 12:36:57AM +0000, Yu, Fenghua wrote:
> > > 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.
> > 
> > You are correct - if there is a need for this, it would be better done in the
> > kernel.
> > 
> > I'm just not sure how to explain both a "procs" and "tasks" interface file in a
> > way that won't confuse people.
> > 
> > We have:
> > 
> > # echo {task-id} > tasks
> >   .... adds a single task to this resource group # cat tasks
> >   ... shows all the tasks in this resource group
> > 
> > and you want:
> > 
> > # echo {process-id} > procs
> >    ... adds all threads in {process-id} to this resource group # cat procs
> >   ... shows all processes (like "cat tasks" above, but only shows main thread in
> > a multi-threads process)
> 
> The advantage of "tasks" is user can allocate each thread into its own partition.
> The advantage of "procs" is convenience for user to just allocate thread group
> lead pid and rest of the thread group members go with the lead.
> 
> If no "procs" is really inconvenience, we may support "procs" in future.
> 
> One way to implement this is we can extend the current interface to accept
> a resctrl file system mount parameter to switch b/w "procs" and "tasks" during
> mount time. So the file sytem has either "procs" or "tasks" during run time. I don't think it's right to have both of them at the same time in the file system.

A mount option doesn't make sense, which just creates more trouble. What's
wrong to have both of 'procs' and 'tasks' at the same time, like cgroup? I
think it's more natural to support both. As for the content of 'procs' and
'tasks', we could follow how cgroup handle them.

Thanks,
Shaohua