Re: RT patch acceptance

[James Bruce]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/