[lkml]   [2009]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: High contention on the sk_buff_head.lock
    Vernon Mauery <> writes:
    > So while this issue really hits -rt kernels hard, it has a real effect on
    > mainline kernels as well. The contention of the spinlocks is amplified
    > when they get turned into rt-mutexes, which causes a double context switch.

    The new adaptive spin heuristics that have been discussed some time
    ago didn't help? Unsurprisingly making locks a lot more expensive
    has drawbacks as you discovered.

    > &list->lock#3: 24517307 24643791 0.71 1286.62 56516392.42 34834296 44904018 0.60 164.79 31314786.02
    > -------------
    > &list->lock#3 15596927 [<ffffffff812474da>] dev_queue_xmit+0x2ea/0x468

    The real "fix" would be probably to use a multi queue capable NIC
    and a NIC driver that sets up multiple queues for TX (normally they
    only do for RX). Then cores or a set of cores (often the number
    of cores is larger than the number of NIC queues) could avoid this
    problem. Disadvantage: more memory use.

    But then again I'm not sure it's worth it if the problem only
    happens in out of tree RT.


    -- -- Speaking for myself only.

     \ /
      Last update: 2009-03-18 22:01    [W:0.020 / U:2.176 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site