On Sat, Jun 30, 2012 at 01:12:18AM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Jun 28, 2012 at 02:56:00PM +0200, Andrea Arcangeli wrote: > > This is where the mm_autonuma structure is being handled. Just like > > sched_autonuma, this is only allocated at runtime if the hardware the > > kernel is running on has been detected as NUMA. On not NUMA hardware > > I think the correct wording is "non-NUMA", not "not NUMA".
That sounds far too easy to me, but I've no idea what's the right is here. > > the memory cost is reduced to one pointer per mm. > > > > To get rid of the pointer in the each mm, the kernel can be compiled > > with CONFIG_AUTONUMA=n. > > > > Signed-off-by: Andrea Arcangeli <[email protected]> > > --- > > kernel/fork.c | 7 +++++++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/kernel/fork.c b/kernel/fork.c > > index 0adbe09..3e5a0d9 100644 > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -527,6 +527,8 @@ static void mm_init_aio(struct mm_struct *mm) > > > > static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct > > *p) > > { > > + if (unlikely(alloc_mm_autonuma(mm))) > > + goto out_free_mm; > > So reading that I would think that on non-NUMA machines this would fail > (since there is nothing to allocate). But that is not the case > (I hope!?) Perhaps just make the function not return any values? It doesn't fail, it returns 0 on non-NUMA. It's identical to alloc_task_autonuma, per prev email. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
