lkml.org 
[lkml]   [2006]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 1/4] - Potential performance bottleneck for Linxu TCP

    * David Miller <davem@davemloft.net> wrote:

    > This is why my suggestion is to preempt_disable() as soon as we grab
    > the socket lock, [...]

    independently of the issue at hand, in general the explicit use of
    preempt_disable() in non-infrastructure code is quite a heavy tool. Its
    effects are heavy and global: it disables /all/ preemption (even on
    PREEMPT_RT). Furthermore, when preempt_disable() is used for per-CPU
    data structures then [unlike for example to a spin-lock] the connection
    between the 'data' and the 'lock' is not explicit - causing all kinds of
    grief when trying to convert such code to a different preemption model.
    (such as PREEMPT_RT :-)

    So my plan is to remove all "open-coded" use of preempt_disable() [and
    raw use of local_irq_save/restore] from the kernel and replace it with
    some facility that connects data and lock. (Note that this will not
    result in any actual changes on the instruction level because internally
    every such facility still maps to preempt_disable() on non-PREEMPT_RT
    kernels, so on non-PREEMPT_RT kernels such code will still be the same
    as before.)

    Ingo
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-11-30 08:01    [W:0.022 / U:63.992 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site