From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754323Ab2I0Sae (ORCPT ); Thu, 27 Sep 2012 14:30:34 -0400 Received: from casper.infradead.org ([85.118.1.10]:46957 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751522Ab2I0Sad convert rfc822-to-8bit (ORCPT ); Thu, 27 Sep 2012 14:30:33 -0400 Message-ID: <1348770584.3292.44.camel@twins> Subject: Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected From: Peter Zijlstra To: Linus Torvalds Cc: Borislav Petkov , Ingo Molnar , Mike Galbraith , Mel Gorman , Nikolay Ulyanitsky , linux-kernel@vger.kernel.org, Andreas Herrmann , Andrew Morton , Thomas Gleixner , Suresh Siddha Date: Thu, 27 Sep 2012 20:29:44 +0200 In-Reply-To: References: <20120926163233.GA5339@x1.osrc.amd.com> <20120926213723.GA27692@liondog.tnic> <1348722568.7059.115.camel@marge.simpson.net> <20120927054742.GA4370@gmail.com> <1348727665.7059.160.camel@marge.simpson.net> <20120927064142.GB5996@gmail.com> <1348728852.7059.171.camel@marge.simpson.net> <20120927071011.GA8980@gmail.com> <20120927180507.GD8527@x1.osrc.amd.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2012-09-27 at 11:19 -0700, Linus Torvalds wrote: > On Thu, Sep 27, 2012 at 11:05 AM, Borislav Petkov wrote: > > On Thu, Sep 27, 2012 at 10:44:26AM -0700, Linus Torvalds wrote: > >> Or could we just improve the heuristics. What happens if the > >> scheduling granularity is increased, for example? It's set to 1ms > >> right now, with a logarithmic scaling by number of cpus. > > > > /proc/sys/kernel/sched_wakeup_granularity_ns=10000000 (10ms) > > ------------------------------------------------------ > > tps = 4994.730809 (including connections establishing) > > tps = 5000.260764 (excluding connections establishing) > > > > A bit better over the default NO_WAKEUP_PREEMPTION setting. > > Ok, so this gives us something possible to actually play with. > > For example, maybe SCHED_TUNABLESCALING_LINEAR is more appropriate > than SCHED_TUNABLESCALING_LOG. At least for WAKEUP_PREEMPTION. Hmm? Don't forget to run the desktop interactivity benchmarks after you're done wriggling with this knob... wakeup preemption is important for most those.