Messages in this thread | | | Date | Wed, 6 Oct 2004 05:17:26 +0200 | From | Andrea Arcangeli <> | Subject | Re: Preempt? (was Re: Cannot enable DMA on SATA drive (SCSI-libsata, VIA SATA)) |
| |
Hello,
On Tue, Oct 05, 2004 at 10:07:34PM -0400, Jeff Garzik wrote: > 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
with any decent profiler places where we're wasting cpus will showup immediatatly, one obvious example that I can recall is the pte_chains rmap code, that wasn't necessairly high latency but still it was very wasteful in terms of cpu, was always at the top of the profiling.
So I disagree with your claim that preempt risks to hide inefficient code, there are many other (probably easier) ways to detect inefficient code than to check the latencies.
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).
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. - 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/
| |