From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754518AbbBZS7j (ORCPT ); Thu, 26 Feb 2015 13:59:39 -0500 Received: from mail.skyhub.de ([78.46.96.112]:51920 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753933AbbBZS7i (ORCPT ); Thu, 26 Feb 2015 13:59:38 -0500 Date: Thu, 26 Feb 2015 19:58:33 +0100 From: Borislav Petkov To: Vikas Shivappa Cc: Vikas Shivappa , linux-kernel@vger.kernel.org, matt.fleming@intel.com, hpa@zytor.com, tglx@linutronix.de, mingo@kernel.org, tj@kernel.org, peterz@infradead.org, will.auld@intel.com, dave.hansen@intel.com, andi.kleen@intel.com, tony.luck@intel.com, kanaka.d.juvva@intel.com Subject: Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection Message-ID: <20150226185833.GG3314@pd.tnic> References: <1424819804-4082-1-git-send-email-vikas.shivappa@linux.intel.com> <1424819804-4082-2-git-send-email-vikas.shivappa@linux.intel.com> <20150224234334.GB3706@pd.tnic> <20150225112153.GB3226@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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. --