From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754326AbdASSqE (ORCPT ); Thu, 19 Jan 2017 13:46:04 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:58156 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754293AbdASSqC (ORCPT ); Thu, 19 Jan 2017 13:46:02 -0500 Date: Thu, 19 Jan 2017 19:03:04 +0100 (CET) From: Thomas Gleixner To: Stephane Eranian cc: Shivappa Vikas , Vikas Shivappa , David Carrillo Cisneros , LKML , x86 , "H. Peter Anvin" , Ingo Molnar , Peter Zijlstra , "Shankar, Ravi V" , "Luck, Tony" , Fenghua Yu , "Kleen, Andi" , h.peter.anvin@intel.com Subject: Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes In-Reply-To: Message-ID: References: <1483740005-23499-1-git-send-email-vikas.shivappa@linux.intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 18 Jan 2017, Stephane Eranian wrote: > On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote: > > > Your use case is specific to HPC and not Web workloads we run. Jobs run > in cgroups which may span all the CPUs of the machine. CAT may be used > to partition the cache. Cgroups would run inside a partition. There may > be multiple cgroups running in the same partition. I can understand the > value of tracking occupancy per CLOSID, however that granularity is not > enough for our use case. Inside a partition, we want to know the > occupancy of each cgroup to be able to assign blame to the top > consumer. Thus, there needs to be a way to monitor occupancy per > cgroup. I'd like to understand how your proposal would cover this use > case. The point I'm making as I explained to David is that we need to start from the allocation angle. Of course can you monitor different tasks or task groups inside an allocation. > Another important aspect is that CQM measures new allocations, thus to > get total occupancy you need to be able to monitor the thread, CPU, > CLOSid or cgroup from the beginning of execution. In the case of a cgroup > from the moment where the first thread is scheduled into the cgroup. To > do this a RMID needs to be assigned from the beginning to the entity to > be monitored. It could be by creating a CQM event just to cause an RMID > to be assigned as discussed earlier on this thread. And then if a perf > stat is launched later it will get the same RMID and report full > occupancy. But that requires the first event to remain alive, i.e., some > process must keep the file descriptor open, i.e., need some daemon or a > perf stat running in the background. That's fine, but there must be a less convoluted way to do that. The currently proposed stuff is simply horrible because it lacks any form of design and is just hacked into submission. > There are also use cases where you want CQM without necessarily enabling > CAT, for instance, if you want to know the cache footprint of a workload > to estimate how if it could be co-located with others. That's a subset of the other stuff because it's all bound to CLOSID 0. So you can again monitor tasks or tasks groups seperately. Thanks, tglx