[lkml]   [2008]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: regression introduced by - timers: fix itimer/many thread hang
    On Mon, 2008-11-10 at 15:42 +0100, Peter Zijlstra wrote:
    > On Mon, 2008-11-10 at 08:38 -0600, Christoph Lameter wrote:
    > > Can we at least somehow make sure that nothing significantly happens in a
    > > timer interrupt on a processor if the thread has not scheduled any events
    > > or not odone any system calls?
    > Do threads actually scale that far? I thought mmap_sem contention and
    > other shared state would render threads basically useless on these very
    > large machines.
    > But afaiu this stuff, the per-cpu loop is only done when an itimer is
    > actually active.


    > The detail I've not looked at is, if when this itimer is indeed active
    > and we are running 256 threads of the same application on all cpus do we
    > then do the per-cpu loop for each tick on each cpu?

    The answer to this question is, "that depends." You can have an itimer
    for a single thread or for the whole thread group. In the former case,
    it never happens; it only does the loops for the thread group case. If
    there is a thread group itimer then of course we have to sum the tick
    count across all CPUs to determine whether the timer has expired.

    Personally, I would argue that it's silly to have an itimer running when
    you have many threads, and if you care about performance it's even
    _more_ silly. But it's sillier yet to be able to wedge the kernel by
    running a program in user space.

    As far as Christoph's concern regarding latency for 8- and 16-processor
    systems, my belief (supported by data I can't discuss, sigh) is that the
    loop adds negligible latency. In fact, it can't really be discussed in
    this way since the existing implementation adds *lots* of latency when
    an itimer is running, since it sums the values across all threads. I
    never collected latency versus number of threads data but it's bad
    enough that at about 4500 threads (on a dual amd64) it took longer than
    a tick to do a tick's worth of processing.
    Frank Mayhar <>
    Google, Inc.

     \ /
      Last update: 2008-11-10 19:03    [W:0.022 / U:2.360 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site