Re: Preempt? (was Re: Cannot enable DMA on SATA drive (SCSI-libsata, VIA SATA))

[Nick Piggin <nickpiggin@yahoo.com.au>]

Jeff Garzik wrote:
> On Wed, Oct 06, 2004 at 12:02:48PM +1000, Nick Piggin wrote:
> 
>>Jeff Garzik wrote:
>>
>>>On Tue, Oct 05, 2004 at 09:52:55PM -0400, Robert Love wrote:
>>>
>>>
>>>>On Tue, 2004-10-05 at 21:40 -0400, Jeff Garzik wrote:
>>>>
>>>>
>>>>
>>>>>And with preempt you're still hiding stuff that needs fixing.  And when 
>>>>>it gets fixed, you don't need preempt.
>>>>>
>>>>>Therefore, preempt is just a hack that hides stuff that wants fixing 
>>>>>anyway.
>>
>>What is it hiding exactly?
> 
> 
> Bugs and high latency code paths that should instead be fixed.
> 

OK - high latency code paths: It doesn't hide critical section latency.
I suppose you could say it hides cond_resched latency (the important
metric for !preempt kernels), but people who care about latency should
enable preempt; those that don't won't (to a point - I agree !preempt
latency needs to be kept in check with the *occasional* cond_resched).

I can't imagine it should hide any bugs though...

> 
> 
>>>>This actually sounds like the argument for preempt, and against
>>>
>>>
>>>As opposed to fixing drivers???  Please fix the drivers and code first.
>>>
>>
>>I thought you just said preempt should be turned off because it
>>breaks things (ie. as opposed to fixing the things that it breaks).
>>
>>But anyway, yeah obviously fixing drivers always == good. I don't
>>think anybody advocated otherwise.
> 
> 
> By _definition_, when you turn on preempt, you hide the stuff I just
> described above.
> 

I really don't see the requirement to have less than a few ms latency
without preempt.

> Hiding that stuff means that users and developers won't see code paths
> that need fixing.  If users and developers aren't aware of code paths
> that need fixing, they don't get fixed.
> 
> Therefore, by advocating preempt, you are advocating a solution _other
> than_ actually making the necessary fixes.
> 

So the "necessary fixes" would be adding more cond_resched checks,
right? In that case, I disagree with your assumption that the fix is
necessary (again, to a point. We don't want 10s of ms latency).