Messages in this thread | | | Date | Tue, 31 May 2005 12:59:23 -0400 | From | James Bruce <> | Subject | Re: RT patch acceptance |
| |
Andi Kleen wrote: > Are you sure it is not only disk IO? In theory updatedb shouldn't > need much CPU, but it eats a lot of memory and causes stalls > in the disk (or at least that was my interpration on the stalls I saw) > If there is really a scheduling latency problem with updatedb > then that definitely needs to be fixed in the stock kernel.
I don't know, Debian's updatedb always seemed to suck up most of the CPU for me. I am using ReiserFS with tail-packing on, which certainly balances on the side of more CPU vs IO. Also I wouldn't be surprised if other distros had some better approach than Debian's, which appears to be a series of "find | sort" commands. As one would expect, find causes most of the system load and sort causes user load spikes.
That said, preempt-RT is certainly not free right now. Sending network messages at 60Hz appears to load this 2GHz system by about 8%, while that workload barely shows up in stock. I figure there's still some optimization work to be done, but obviously it's unlikely to ever be as efficient as non-preempt-RT. The more interesting question is whether it's any slower with the RT patch applied, but preemption turned off. From the implementation approach, I don't think it will show any difference from stock, but it's certainly something we've got to test a fair amount to be sure.
- Jim Bruce - 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/
| |