From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932510AbbERTVF (ORCPT <rfc822;w@1wt.eu>);
	Mon, 18 May 2015 15:21:05 -0400
Received: from mail.skyhub.de ([78.46.96.112]:54451 "EHLO mail.skyhub.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754243AbbERTVE (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 18 May 2015 15:21:04 -0400
Date: Mon, 18 May 2015 21:20:57 +0200
From: Borislav Petkov <bp@alien8.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Vikas Shivappa <vikas.shivappa@intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
        tj@kernel.org, peterz@infradead.org,
        Matt Fleming <matt.fleming@intel.com>,
        "Auld, Will" <will.auld@intel.com>, peter.zijlstra@intel.com,
        h.peter.anvin@intel.com, "Juvva, Kanaka D" <kanaka.d.juvva@intel.com>,
        mtosatti@redhat.com
Subject: Re: [PATCH 2/7] x86/intel_rdt: Adds support for Class of service
 management
Message-ID: <20150518192057.GA23653@pd.tnic>
References: <1431370976-31115-1-git-send-email-vikas.shivappa@linux.intel.com>
 <1431370976-31115-3-git-send-email-vikas.shivappa@linux.intel.com>
 <alpine.DEB.2.11.1505152030400.4225@nanos>
 <alpine.DEB.2.10.1505151508420.14506@vshiva-Udesk>
 <alpine.DEB.2.11.1505182020030.4225@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1505182020030.4225@nanos>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, May 18, 2015 at 08:41:53PM +0200, Thomas Gleixner wrote:
> > > > +	}
> > > > +
> > > > +	set_bit(0, rdtss_info.closmap);
> > > > +	rdt_root_group.clos = 0;
> > > > +	ccm = &ccmap[0];
> > > > +	bitmap_set(&ccm->cache_mask, 0, max_cbm_len);
> > > > +	ccm->clos_refcnt = 1;
> > > > +
> > > >  	pr_info("Max bitmask length:%u,Max ClosIds: %u\n", max_cbm_len,
> > > > maxid);
> > > 
> > > We surely do not want to sprinkle these all over dmesg.
> > 
> > This is just printed once! how is that sprinke all over?   - we have a dmsg
> > print for Cache monitoring as well when cqm is enabled.
> 
> Sorry, mapped that to the wrong function. Though the message itself is
> horrible. 
> 
> 	  "Max bitmask length:32,Max ClosIds: 16"	
> 
> With some taste and formatting applied this would read:
> 
>      	  "Max. bitmask length: 32, max. closids: 16"
> 
> Can you spot the difference?

I sure can.

Also, I'd still like to ask about the usability of that message. What
does it bring us?

And if the dmesg ring buffer wraps around and it gets overwritten, what
do we do then?

So basically this message does tell us about some max bitmap length and
so on. IOW, useless, right?

Can it be read out from CPUID maybe? If so, stuff which is interested in
it can generate it then.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--