lkml.org 
[lkml]   [2008]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/1] cpumask: smp_call_function_many()
Date
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.


\
 
 \ /
  Last update: 2008-11-20 05:47    [W:0.081 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site