Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH 1/1] cpumask: smp_call_function_many() | Date | Thu, 20 Nov 2008 15:14:08 +1030 |
| |
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 :)
> 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.
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 :(
Rusty.
| |