[lkml]   [2005]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-31 20:34    [W:0.021 / U:31.324 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site