Messages in this thread | | | From | Nick Piggin <> | Subject | Re: [PATCH 1/1] cpumask: smp_call_function_many() | Date | Thu, 20 Nov 2008 17:57:07 +1100 |
| |
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.
| |