linux-kernel - Re: [RFD] CAT user space interface revisited

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:	Tue, 24 Nov 2015 15:31:24 +0800
From:	Chao Peng <chao.p.peng@...ux.intel.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Luiz Capitulino <lcapitulino@...hat.com>,
	Vikas Shivappa <vikas.shivappa@...el.com>,
	Tejun Heo <tj@...nel.org>, Yu Fenghua <fenghua.yu@...el.com>
Subject: Re: [RFD] CAT user space interface revisited

On Wed, Nov 18, 2015 at 07:25:03PM +0100, Thomas Gleixner wrote:
> 
> Let's look at partitioning itself. We have two options:
> 
>    1) Per task partitioning
> 
>    2) Per CPU partitioning
> 
> So far we only talked about #1, but I think that #2 has a value as
> well. Let me give you a simple example.

I would second this. In practice per CPU partitioning is useful for
realtime as well. And I can see three possible solutions:

     1) What you suggested below, to address both problems in one
        framework. But I wonder if it would end with too complex.

     2) Achieve per CPU partitioning with per task partitioning. For
        example, if current CAT patch can solve the kernel threads
	problem, together with CPU pinning, we then can set a same CBM
	for all the tasks/kernel threads run on an isolated CPU. 

     3) I wonder if it feasible to separate the two requirements? For
        example, divides the work into three components: rdt-base,
	per task interface (current cgroup interface/IOCTL or something)
	and per CPU interface. The two interfaces are exclusive and
	selected at build time. One thing to reject this option would be
	even with per CPU partitioning, we still need per task partitioning,
	in that case we will go to option 1) again.

Thanks,
Chao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/