Messages in this thread | | | Subject | Re: [PATCH 2/4] generic-smp: remove kmalloc usage | From | Peter Zijlstra <> | Date | Thu, 19 Feb 2009 10:10:29 +0100 |
| |
On Thu, 2009-02-19 at 15:01 +1030, Rusty Russell wrote: > On Thursday 19 February 2009 02:35:35 Ingo Molnar wrote: > > > > * Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > > On Tuesday 17 February 2009 20:13:59 Ingo Molnar wrote: > > > > We should not bend backwards trying to preserve that kmalloc() > > > > [and prove that it's safe and race-free] - i.e. the burden of > > > > proof is on the person insisting that it's needed, not on the > > > > person wanting to remove it. > > > > > > Respectfully disagree. The kmalloc has been there for a very long time, > > > and doing fine AFAICT. > > > > The kmalloc(GFP_ATOMIC) has been in kernel/smp.c for about half > > a year > > Oops, yes. > > So if we care about the kmalloc, why didn't we see benchmarks when we > switched from the x86 smp_call_function_mask to the generic one? Or did > I just miss them (there's nothing in the git commit). > > Now, I think the current patch is quite neat and may not been benchmarks to > justify it, but it'd still be nice if it were faster, but noone seems to know.
I think the problem is that even on a lively machine these routines just aren't called that often:
CAL: 74 104 93 116 Function call interrupts make clean; make -j8 bzImage CAL: 74 104 93 116 Function call interrupts
We could of course construct some artificial ubench to stress it...
| |