From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752042Ab1ARKaV (ORCPT ); Tue, 18 Jan 2011 05:30:21 -0500 Received: from casper.infradead.org ([85.118.1.10]:43632 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243Ab1ARKaT convert rfc822-to-8bit (ORCPT ); Tue, 18 Jan 2011 05:30:19 -0500 Subject: Re: [PATCH 00/21] mm: Preemptibility -v6 From: Peter Zijlstra To: Hugh Dickins Cc: Andrew Morton , Benjamin Herrenschmidt , David Miller , Nick Piggin , Martin Schwidefsky , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org In-Reply-To: References: <20101126143843.801484792@chello.nl> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Tue, 18 Jan 2011 11:30:47 +0100 Message-ID: <1295346647.30950.477.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2011-01-17 at 23:12 -0800, Hugh Dickins wrote: > I understand you're intending to update your preemptible mmu_gather > patchset against 2.6.38-rc1, so I've spent a while looking through > (and running) your last posted version (plus its two fixes from BenH). > > I've had no problems in running it, I can't tell if it's quicker or > slower than the unpatched. The only argument against the patchset, > really, would be performance: and though there are no bad reports on > it as yet, I do wonder how we proceed if a genuine workload shows up > which is adversely affected. Oh well, silly to worry about the > hypothetical I suppose. > Wow, _HUGE_ review, thanks! I'll slowly make my way through it when I do the rebase against .38-rc1, most suggestions look very good indeed. And as to performance, there's the no-regression report from Yanmin running it through the Intel test farm. However Nick also had a particular workload he wanted to test, Nick, do you think you've got a few spare minutes to dig that workload up and give it a run? But I guess you're right, there's always a chance someone hits something, and I guess there's nothing to it but to deal with it when that comes..