Messages in this thread |  | | | Date | Thu, 12 Jul 2012 20:08:28 +0200 | | From | Andrea Arcangeli <> | | Subject | Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma |
| |
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 <aarcange@redhat.com> > > --- > > 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.
|  |