From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759736AbYEGOha (ORCPT ); Wed, 7 May 2008 10:37:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755709AbYEGOhQ (ORCPT ); Wed, 7 May 2008 10:37:16 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:43180 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754761AbYEGOhN (ORCPT ); Wed, 7 May 2008 10:37:13 -0400 Date: Wed, 7 May 2008 07:36:42 -0700 (PDT) From: Linus Torvalds To: Andi Kleen cc: Matthew Wilcox , "Zhang, Yanmin" , Ingo Molnar , LKML , Alexander Viro , Andrew Morton Subject: Re: AIM7 40% regression with 2.6.26-rc1 In-Reply-To: <87hcdab8zp.fsf@basil.nowhere.org> Message-ID: References: <1210052904.3453.30.camel@ymzhang> <20080506114449.GC32591@elte.hu> <1210126286.3453.37.camel@ymzhang> <1210131712.3453.43.camel@ymzhang> <87lk2mbcqp.fsf@basil.nowhere.org> <20080507114643.GR19219@parisc-linux.org> <87hcdab8zp.fsf@basil.nowhere.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 May 2008, Andi Kleen wrote: > > I am aware of that commit, thank you, but the comment was refering to that it > came with about zero justification why it was done. For the left over BKL > regions which are relatively short surely a spinlock would be better than a > semaphore? So PREEMPT_BKL should have been removed, not !PREEMPT_BKL. I do agree. I think turning the BKL into a semaphore was fine per se, but that was when semaphores were fast. Considering the apparent AIM regressions, we really either need to revert the semaphore consolidation, or we need to fix the kernel lock. And by "fixing", I don't mean removing it - it will happen, but it almost certainly won't happen for 2.6.26. The easiest approach would seem to just turn the BKL into a mutex instead, which should hopefully be about as optimized as the old semaphores. But my preferred option would indeed be just turning it back into a spinlock - and screw latency and BKL preemption - and having the RT people who care deeply just work on removing the BKL in the long run. Is BKL preemption worth it? Sounds very dubious. Sounds even more dubious when we now apparently have even more reason to aim for removing the BKL rather than trying to mess around with it. Linus