Re: [PATCH 1/1] cpumask: smp_call_function_many()

[Rusty Russell <rusty@rustcorp.com.au>]

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.