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

From: Vikas Shivappa
Date: Tue May 19 2015 - 13:35:28 EST




On Mon, 18 May 2015, Borislav Petkov wrote:

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.

Yes the max bitmask and max closid can be read from cpuid. the presence of rdt and l3 cache alloc is indicated by rdt and cat_l3 in /proc/cpuinfo. So even if this message gets overwritten , user can see the feature enabled in kernel.

Can be modified somthing similar to "Intel cache allocation enabled" as well.

Thanks,
Vikas


--
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/