|From:||James Bruce <bruce-AT-andrew.cmu.edu>|
|To:||Andi Kleen <ak-AT-muc.de>|
|Subject:||Re: RT patch acceptance|
|Date:||Tue, 31 May 2005 12:59:23 -0400|
|Cc:||Nick Piggin <nickpiggin-AT-yahoo.com.au>, Sven-Thorsten Dietrich <sdietrich-AT-mvista.com>, Ingo Molnar <mingo-AT-elte.hu>, dwalker-AT-mvista.com, hch-AT-infradead.org, akpm-AT-osdl.org, linux-kernel-AT-vger.kernel.org|
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
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds