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

[Nick Piggin]

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).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/