From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 00 of 11 v5] NUMA aware credit scheduling Date: Tue, 16 Apr 2013 17:45:13 +0100 Message-ID: References: <516D6AC802000078000CD9D3@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <516D6AC802000078000CD9D3@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Dario Faggioli , George Dunlap Cc: Tim Deegan , Juergen Gross , Ian Jackson , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 16/04/2013 14:14, "Jan Beulich" wrote: >>>> On 16.04.13 at 14:16, George Dunlap wrote: >> On Tue, Apr 16, 2013 at 9:44 AM, Dario Faggioli >> wrote: >>> On gio, 2013-04-11 at 13:41 +0100, George Dunlap wrote: >>>> Keir, >>>> >>> Ping? >> >> Given the state we are in the release cycle, and the importance of >> this patch, and the relative simplicity of the changes in Xen outside >> of the scheduler: >> >> Tim and Jan, would one of you be willing to use an "Apply unless Keir >> objects" policy? > > Going through patches 1...5 again, > > - 1 and 2 touch tools/, but don't have a tools maintainer ack yet > - 1 touches the public interface (even if only the one affecting > the tools) > - 1's hypervisor changes look mostly mechanical, but it's not like > this changes just a handful of lines > - 2's hypervisor changes look like I could agree to such a one-off > policy > - 3 and 4 are only/mostly scheduler changes, and the little bit of > 4 that isn't I would also be fine with the "adjusted" policy > - 5 has a public interface change again I had a look through them this afternoon and there was nothing contentious there in my opinion. The non-scheduler and public interface changes were all good. So you can have my: Acked-by: Keir Fraser For patches 1...5. -- Keir > So for the whole 1...5 I wouldn't want to override the policy in > the way you suggest. Whether we want to change that policy > going forward, or nominate a second "everything-else" > maintainer is a separate thing. > > Jan >