Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TDyjz-00025q-LO for pgsql-performance@postgresql.org; Tue, 18 Sep 2012 14:25:31 +0000 Received: from host36.ns3.it ([80.79.54.36] helo=mail.opinioni.net) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TDyjr-0000FN-8r for pgsql-performance@postgresql.org; Tue, 18 Sep 2012 14:25:31 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.opinioni.net (Postfix) with ESMTP id B7A2E46CF7B; Tue, 18 Sep 2012 16:32:10 +0200 (CEST) Received: from mail.opinioni.net ([127.0.0.1]) by localhost (opinioni.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia8pefCAXjhm; Tue, 18 Sep 2012 16:32:10 +0200 (CEST) Received: from [192.168.1.50] (85-18-94-64.ip.fastwebnet.it [85.18.94.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.opinioni.net (Postfix) with ESMTPS id 9309046CF66; Tue, 18 Sep 2012 16:32:10 +0200 (CEST) Message-ID: <50588450.9090709@opinioni.net> Date: Tue, 18 Sep 2012 16:25:20 +0200 From: Andrea Suisani User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Merlin Moncure CC: pgsql-performance@postgresql.org Subject: Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets References: <5058264D.5090702@opinioni.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201209/86 X-Sequence-Number: 47832 [cut] >>>> Kernel config - http://pastebin.com/cFpg5JSJ >>>> >>>> Any ideas? >>> >>> >>> Did you tell LKML? It seems like a kind of change that could be found >>> using git bisect of Linux, albiet laboriously. >> >> just a pointer to LKML thread: >> >> https://lkml.org/lkml/2012/9/14/99 > > There's some interesting discussion of postgres spinlocks in the thread: > > "Yes, postgress performs loads better with it's spinlocks, but due to > that, it necessarily _hates_ preemption." another one: https://lkml.org/lkml/2012/9/15/39 quoting the relevant piece: On Sat, Sep 15, 2012 at 06:11:02AM +0200, Mike Galbraith wrote: > My wild (and only) theory is that this is userspace spinlock related. > If so, starting the server and benchmark SCHED_BATCH should not only > kill the regression, but likely improve throughput as well. after that message Borislav Petkov tried to to exactly that using schedtool(8) (tool to query and set CPU scheduling parameters) and he can confirm that performace are "even better than the results with 3.5 (had something around 3900ish on that particular configuration)." Andrea