lkml.org 
[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Preempt? (was Re: Cannot enable DMA on SATA drive (SCSI-libsata, VIA SATA))
Jeff Garzik wrote:
> You're making my point for me. If the bandaid (preempt) is not active,
> then the system can be accurated profiled. If preempt is active, then
> it is potentially hiding trouble spots.
>
> The moral of the story is not to use preempt, as it
> * potentially hides long latency code paths
> * potentially introduces bugs, as we've seen with net stack and many
> other pieces of code
> * is simply not needed, if all code paths are fixed

One can also look onto it from another angle:
* conviniently resolves long latency code paths that can't be avoided
* uncovers bugs that need to be fixed
* implicitly fixes code paths

It seems to me that you are mixing latency of the system, efficiency of
the driver functions, and performance of the system in the way it suits
your arguments.

Those three influent each other, but should be looked at and solved
separately.

Preempt is a fix for latency. It doesn't (and can't) fix efficiency and
performace. If you are using latency as a measure for efficiency and
performance, you are mixing apples and oranges with bananas.

Unefficient driver function (or code path) will not become efficient if
you sprinkle it with cond_resched (it will only reduce the latency of
the system). As you conviniently said, you are just putting band aid on
the problem, instead of fixing it. Not different than using preept
kernel, really. Only more time spent on it by developer, that might be
used better somewhere else (like making code path more efficient).

Performance of the system might be a bit lower with preempt kernel. But
most of those that would notice or care (0.1% of users? probably less)
would probably be happier without cond_resched executed thousands a time
per second too, and would happily sacrifice latency to high performance.

Finally, the bugs. Bugs need to be fixed. Period. If bug goes away
when somebody turns off preempt on uniprocessor system, it may as well
hit back when you move to non-preempt SMP system in even more obscure
ways (because than you really have code paths executed in parallel).
Telling somebody to try with non-preempt kernel should be debugging
step, not the solution.

--
Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited
Systems Administrator 1499 Buffalo Place
Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.064 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site