Re: [PATCH 2/7] x86/intel_rdt: Adds support for Class of service management

[Borislav Petkov]

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.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/