Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266615AbUJFB20 (ORCPT ); Tue, 5 Oct 2004 21:28:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266626AbUJFB20 (ORCPT ); Tue, 5 Oct 2004 21:28:26 -0400 Received: from smtp209.mail.sc5.yahoo.com ([216.136.130.117]:49554 "HELO smtp209.mail.sc5.yahoo.com") by vger.kernel.org with SMTP id S266615AbUJFB2Y (ORCPT ); Tue, 5 Oct 2004 21:28:24 -0400 Message-ID: <41634A34.20500@yahoo.com.au> Date: Wed, 06 Oct 2004 11:28:20 +1000 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: Jeff Garzik CC: Roland Dreier , linux-kernel@vger.kernel.org Subject: Re: Preempt? (was Re: Cannot enable DMA on SATA drive (SCSI-libsata, VIA SATA)) References: <4136E4660006E2F7@mail-7.tiscali.it> <41634236.1020602@pobox.com> <52is9or78f.fsf_-_@topspin.com> <4163465F.6070309@pobox.com> In-Reply-To: <4163465F.6070309@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1325 Lines: 37 Jeff Garzik wrote: > Roland Dreier wrote: > >> Jeff> I strongly recommend disabling kernel preemption. It is a >> Jeff> hack that hides bugs. >> >> Why do you say that? Preempt seems to be the cleanest way to low >> latency, and if anything it exposes locking bugs and races rather than >> hiding anything. > > > Clean? Hardly. It breaks up code paths that were never written to be > broken up. But lots of things change. Unserialising the kernel broke code paths. > The proper fix is to locate and fix high latency code paths. > Preempt does nothing but hide those high latency code paths, and > discourage people from seeking a better solution. > > Fix the drivers, rather than bandaid over them with preempt. > > If all code paths in the kernel were low latency, then you would not > need preempt at all. > When you say low latency, you mean small lock hold times, *and* cond_rescheds placed everywhere - it is this second requirement that isn't the cleanest way of doign things. With preempt, sure you still need small lock hold times. No big deal. - 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/