linux-kernel - Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection

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:	Thu, 26 Feb 2015 11:12:28 -0800 (PST)
From:	Vikas Shivappa <vikas.shivappa@...el.com>
To:	Borislav Petkov <bp@...en8.de>
cc:	Vikas Shivappa <vikas.shivappa@...el.com>,
	Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
	linux-kernel@...r.kernel.org, matt.fleming@...el.com,
	hpa@...or.com, tglx@...utronix.de, mingo@...nel.org, tj@...nel.org,
	peterz@...radead.org, will.auld@...el.com, dave.hansen@...el.com,
	andi.kleen@...el.com, tony.luck@...el.com, kanaka.d.juvva@...el.com
Subject: Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology
 detection



On Thu, 26 Feb 2015, Borislav Petkov wrote:

> On Thu, Feb 26, 2015 at 10:19:42AM -0800, Vikas Shivappa wrote:
>> This would be an indication that the System support RDT. On a system with
>> RDT would see a print.
>>
>> intel_rdt: cbmlength: xx , CLOss:xx
>
> Ok, so I have a capacity bitmask of length xx and yy classes of service.
> And?
>
> Are you expecting for tools or experienced users to grep dmesg to find
> that information?
>
> Uh, but what happens on a machine which has a small log buffer and which
> has wrapped around and that information has been overwritten?

Yes, this is not the only way to see if the feature is enabled. It can be seen 
in cpuinfo like you mention below. 
The root's cbm mask represents the max cbm length already -
that can be seen by the user as defined in the documentation.
It is under consideration to add Max closids or something like clos ids 
available to be shown in the root cgroup once there are more resources and more 
such parameters required to be exposed to user. It would be easier to view the 
resources like CPUID availability through cgroup interface itself rather than 
add an other interface for the same.

>
> See what I mean?
>
> If you really want to communicate this information to someone, you
> should use more robust methods like make userspace use CPUID directly or
> expose that information in sysfs if CPUID is not an option (but I can't
> imagine why it wouldn't be).
>
> This flaky message which can get overwritten and gets used only by a
> small percentage of people(?) (I haven't reached the part which tells
> me the use cases for that resource management yet) is purely useless in
> dmesg.
>
> Even /proc/cpuinfo, which will have "rdt" et all in there according to
> the defines you're adding, would be a much better way to detect what's
> supported quickly than the message.
>
> HTH.
>
> -- 
> Regards/Gruss,
>    Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --
>
--
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/