[lkml]   [2001]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Significant performace improvements on reiserfs systems
    On Thu, 2001-09-20 at 19:15, Andrea Arcangeli wrote:
    > All I'm saying is that you should check for >= 0, not == 0.

    And I am saying we already keep track of that, we have a preemption

    > But anwyays it's pretty depressing to see such a costly check needed to
    > get latency right with the preemptive kernel approch, with
    > non-preemptive kernel we'd need to just check need_resched and a call
    > schedule in the unlikely case so it would be even lighter :) and no
    > fixed costs in UP spinlocks, per-cpu datastrctures etc... The point of
    > preemptive kernel would be just to prevent us to put such kind of
    > explicit (costly) checks in the code. My theory was that the cpu-costly
    > loops are mostly protected by some lock anyways and the fact you're
    > writing such horrid (but helpful) code is a kind of proof.

    Well, with the preemptive kernel we already account for 90% of the high
    latency areas.

    Doing the "horrid" solution may solve some other issues, but agreeably
    you are right its not the prettiest solution.

    I don't agree, however, that its that much more costly, and maybe I am
    missing something. Assuming we are SMP (and thus have locks), where is
    there a lot more overhead? We check current->need_resched (which we
    dont _have_ to), call unlock_kernel() and then call lock_kernel(), with
    preemption happening automatically in between. The preemption code
    merely checks a counter and calls preempt_schedule() if needed.

    Now, yes, this is not ideal. Ideally we don't need any of this muck.
    Ideally preemption provides everything we need. So, towards the future,
    we can work towards that. For very short locks, we could just disable
    interrupts (a lot less overhead). For long-held locks, we can replace
    them with a more efficient lock -- spin-then-sleep or a
    priority-inheriting mutex lock, for example.

    I don't want to confuse the above, which is perhaps an ideal system for
    inclusion in 2.5, with trying to lower latency further for those who
    care via conditional scheduling and the such.

    We already have average latency of <1ms with peaks 10-50ms.

    Robert M. Love
    rml at
    rml at

    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-03-22 13:03    [W:0.039 / U:42.772 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site