Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 29 Jan 2002 21:50:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 29 Jan 2002 21:50:46 -0500 Received: from nrg.org ([216.101.165.106]:20320 "EHLO nrg.org") by vger.kernel.org with ESMTP id ; Tue, 29 Jan 2002 21:50:28 -0500 Date: Tue, 29 Jan 2002 18:50:21 -0800 (PST) From: Nigel Gamble Reply-To: nigel@nrg.org To: Robert Love cc: Andrew Morton , Linus Torvalds , , Subject: Re: [PATCH] 2.5: push BKL out of llseek In-Reply-To: <1012357211.817.67.camel@phantasy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 29 Jan 2002, Robert Love wrote: > On Tue, 2002-01-29 at 20:26, Andrew Morton wrote: > > Just a little word of caution here. Remember the > > apache-flock-synchronisation fiasco, where removal > > of the BKL halved Apache throughput on 8-way x86. > > > > This was because the BKL removal turned serialisation > > on a quick codepath from a spinlock into a schedule(). Yes, but the other factor to consider here is why did the extra schedule take place at all? I think this is a actually a scheduler issue, and I'm hoping that the new scheduler will behave better in this case. A call to schedule() should not happen unless the woken process has a higher priority than the process that did the unlock, but the old scheduler evidently always calculated this to be the case. But we really want the process that did the unlock to continue running (until the end of its timeslice, if not preempted or blocked before then), just as it would when the lock was a spinlock. It would be interesting to see whether the new scheduler gets this right. Am I remembering the problem correctly? Nigel Gamble nigel@nrg.org Mountain View, CA, USA. http://www.nrg.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/