Message-ID: <416367BC.4090302@yahoo.com.au>
Date: Wed, 06 Oct 2004 13:34:20 +1000
From: Nick Piggin <nickpiggin@yahoo.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
MIME-Version: 1.0
To: Andrea Arcangeli <andrea@novell.com>
CC: Jeff Garzik <jgarzik@pobox.com>, Robert Love <rml@novell.com>,
       Roland Dreier <roland@topspin.com>, 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> <41634A34.20500@yahoo.com.au> <41634CF3.5040807@pobox.com> <1097027575.5062.100.camel@localhost> <20041006015515.GA28536@havoc.gtf.org> <41635248.5090903@yahoo.com.au> <20041006020734.GA29383@havoc.gtf.org> <20041006031726.GK26820@dualathlon.random>
In-Reply-To: <20041006031726.GK26820@dualathlon.random>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1631
Lines: 39

Andrea Arcangeli wrote:

> The one argument I've against preempt is that the claim that preempt
> doesn't spread cond_resched all over the place is false. It can spread
> even more of them as implicit ones. They're not visible to the developer
> but they're visible to the cpu. So disabling preempt and putting
> finegriend cond_resched should allow us to optimize the code better, and
> actually _reduce_ the number of cond_resched (cond_resched as the ones
> visible to the cpu, not the ones visible to the kernel developer).
> 

You are right. Sort of :)

But 1, we *want* them to be less visible to the kernel developer,
so this is still a plus.

2, delimiting critical sections with the checks (as preempt does)
rigorously defines scheduling latency as the minimum possible (ie.
critical section latency).

3, all of the overhead is removed if you don't care about latency
and thus turn off preempt.

> I wonder if anybody ever counted the number of implicit cond_resched
> placed by preempt and compared them to the number of explicit
> cond_resched needed without preempt.
> 

There is no denying that there is a performance penalty with preempt
Actually it has to pay double because the bkl means it can't optimise
cond_resched away entirely (would be nice to kill the bkl one day).

But I think that the impact is small enough so that nobody who wants
sub-ms latency will care.
-
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/