From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754438AbdASUCQ (ORCPT ); Thu, 19 Jan 2017 15:02:16 -0500 Received: from mga03.intel.com ([134.134.136.65]:5818 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751341AbdASUCO (ORCPT ); Thu, 19 Jan 2017 15:02:14 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,255,1477983600"; d="scan'208";a="1115148642" Date: Thu, 19 Jan 2017 11:59:21 -0800 (PST) From: Shivappa Vikas X-X-Sender: vikas@vshiva-Udesk To: Peter Zijlstra cc: Thomas Gleixner , Shivappa Vikas , Vikas Shivappa , davidcc@google.com, eranian@google.com, linux-kernel@vger.kernel.org, x86@kernel.org, hpa@zytor.com, mingo@kernel.org, ravi.v.shankar@intel.com, tony.luck@intel.com, fenghua.yu@intel.com, andi.kleen@intel.com, h.peter.anvin@intel.com Subject: Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes In-Reply-To: <20170118095658.GC6485@twins.programming.kicks-ass.net> Message-ID: References: <1483740005-23499-1-git-send-email-vikas.shivappa@linux.intel.com> <20170118095658.GC6485@twins.programming.kicks-ass.net> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Peterz, On Wed, 18 Jan 2017, Peter Zijlstra wrote: > On Wed, Jan 18, 2017 at 09:53:02AM +0100, Thomas Gleixner wrote: >> The whole approach you and David have taken is to whack some desired cgroup >> functionality and whatever into CQM without rethinking the overall >> design. And that's fundamentaly broken because it does not take cache (and >> memory bandwidth) allocation into account. >> >> I seriously doubt, that the existing CQM/MBM code can be refactored in any >> useful way. As Peter Zijlstra said before: Remove the existing cruft >> completely and start with completely new design from scratch. >> >> And this new design should start from the allocation angle and then add the >> whole other muck on top so far its possible. Allocation related monitoring >> must be the primary focus, everything else is just tinkering. > > Agreed, the little I have seen of these patches is quite horrible. And > there seems to be a definite lack of design; or at the very least an > utter lack of communication of it. the 1/12 Documentation patch describes the interface. Basically we are just trying to support the task and cgroup monitoring. By the design document, do you want a document describing how we enable the cgroup for cqm since its a special case? (which would include all the arch_info in the perf_cgroup we add to keep track of hierarchy in the driver , etc ..) Thanks, Vikas > > The approach, in so far that I could make sense of it, seems to utterly > rape perf-cgroup. I think Thomas makes a sensible point in trying to > match it to the CAT stuffs. >