Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932562AbbBZLhr (ORCPT ); Thu, 26 Feb 2015 06:37:47 -0500 Received: from mail-we0-f170.google.com ([74.125.82.170]:35233 "EHLO mail-we0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752883AbbBZLhp (ORCPT ); Thu, 26 Feb 2015 06:37:45 -0500 Date: Thu, 26 Feb 2015 12:37:39 +0100 From: Ingo Molnar To: "Luck, Tony" Cc: Peter Zijlstra , Vikas Shivappa , "linux-kernel@vger.kernel.org" , "Shivappa, Vikas" , "Fleming, Matt" , "hpa@zytor.com" , "tglx@linutronix.de" , "tj@kernel.org" , "Auld, Will" , "Hansen, Dave" , "Kleen, Andi" , "Juvva, Kanaka D" Subject: Re: [PATCH V4 0/7] x86/intel_rdt: Intel Cache Allocation Technology Message-ID: <20150226113739.GB4191@gmail.com> References: <1424819804-4082-1-git-send-email-vikas.shivappa@linux.intel.com> <20150225092657.GH5029@twins.programming.kicks-ass.net> <3908561D78D1C84285E8C5FCA982C28F329ED336@ORSMSX114.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F329ED336@ORSMSX114.amr.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1508 Lines: 43 * Luck, Tony wrote: > > The CAT thing was annoying already, but at least one > > can find that in the SDM, this RDT thing, not a single > > mention. > > The problems of development at the bleeding edge. Would > you rather Linux sat on the sidelines until there are > enough Google hits from other users of new features? Well, we'd prefer there to be A) published documentation, or, lacking published documentation, there be B) a coherent technical description within the code itself what the purpose is and how it all works conceptually (minus the buzzwords), so that we have a common starting point when reviewing it. > Technology: Intel Resource Director Technology > > Description: Allows the hypervisor to monitor Last Level Cache usage at the application > and VM levels. > > Benefit: Helps to improve performance and efficiency by providing better > information for scheduling, load balancing, and workload migration > > Which isn't any help in evaluating this patch series :-( No, but it already tells us more than the 0/7 description of the patch series did! It should be possible to improve on that. Maintainers reverse engineering the implementation is an inefficient approach. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/