User: Password:
|
|
Subscribe / Log in / New account

Re: RT patch acceptance

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
Archive-link:  Article, Thread

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


(Log in to post comments)


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds