[lkml]   [2008]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/1] cpumask: smp_call_function_many()
    On Thursday 20 November 2008 15:44, Rusty Russell wrote:
    > On Thursday 20 November 2008 13:51:49 Nick Piggin wrote:
    > > I don't like changing of this whole smp_call_function_many scheme
    > > with no justification or even hint of it in the changelog.
    > Hi Nick,
    > Hmm, it said "if allocation fails we fallback to smp_call_function_single
    > rather than using the baroque quiescing code."
    > More words would have been far less polite :)

    Hmm, OK I missed that.

    > > Of course it is obvious that smp_call_function_mask can be implemented
    > > with multiple call singles. But some architectures that can do
    > > broadcast IPIs (or otherwise a little extra work eg. in programming
    > > the interrupt controller) will lose here.
    > >
    > > Also the locking and cacheline behaviour is probably actually worse.
    > Dude, we've failed kmalloc. To paraphrase Monty Python, the parrot is
    > fucked. By this stage the disks are churning, the keyboard isn't responding
    > and the OOM killer is killing the mission-critical database and other vital
    > apps. Everything else is failing on random syscalls like unlink(). Admins
    > wondering how long it'll take to fsck if they just hit the big red switch
    > now.

    Oh no it happens. It's a GFP_ATOMIC allocation isn't it? But yeah it's not
    performance critical.

    > OK, maybe it's not that bad, but worrying about cacheline behaviour? I'd
    > worry about how recently that failure path has been tested.
    > I can prepare a separate patch which just changes this over, rather than
    > doing it as part of the smp_call_function_many() conversion, but I couldn't
    > stomach touching that quiescing code :(

    What's wrong with it? It's well commented and I would have thought pretty
    simple. A bit ugly, but straightforward. I still don't really see why it
    needs changing.

     \ /
      Last update: 2008-11-20 07:59    [W:0.021 / U:5.704 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site