From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932288AbbERSoz (ORCPT ); Mon, 18 May 2015 14:44:55 -0400 Received: from www.linutronix.de ([62.245.132.108]:50499 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932200AbbERSoy (ORCPT ); Mon, 18 May 2015 14:44:54 -0400 Date: Mon, 18 May 2015 20:45:03 +0200 (CEST) From: Thomas Gleixner To: Vikas Shivappa cc: Vikas Shivappa , x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org, tj@kernel.org, peterz@infradead.org, matt.fleming@intel.com, will.auld@intel.com, peter.zijlstra@intel.com, h.peter.anvin@intel.com, kanaka.d.juvva@intel.com, mtosatti@redhat.com Subject: Re: [PATCH 4/7] x86/intel_rdt: Implement scheduling support for Intel RDT In-Reply-To: Message-ID: References: <1431370976-31115-1-git-send-email-vikas.shivappa@linux.intel.com> <1431370976-31115-5-git-send-email-vikas.shivappa@linux.intel.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 May 2015, Vikas Shivappa wrote: > On Fri, 15 May 2015, Thomas Gleixner wrote: > > On Mon, 11 May 2015, Vikas Shivappa wrote: > > > + /* > > > + * This needs to be fixed > > > + * to cache the whole PQR instead of just CLOSid. > > > + * PQR has closid in high 32 bits and CQM-RMID in low 10 bits. > > > + * Should not write a 0 to the low 10 bits of PQR > > > + * and corrupt RMID. > > > > And why is this not fixed __BEFORE__ this patch? You can do the > > changes to struct intel_cqm_state in a seperate patch and then do the > > proper implementation from the beginning instead of providing a half > > broken variant which gets replaced in the next patch. > > Ok , can fix both items in your comments. Reason I had it seperately is that > the cache affects both cmt and cache allocation patches. And that's the wrong reason. Sure it affects both, but we first prepare the changes to the existing code and then build new stuff on top of it not the other way round. Building the roof before the basement is almost never a good idea. Thanks, tglx