Mailing List Archive: Linux: Kernel

[PATCH 20/40] autonuma: alloc/free/init mm_autonuma

Index | Next | Previous | View Threaded

aarcange at redhat

Jun 28, 2012, 5:56 AM

Post #1 of 9 (119 views)
Permalink

[PATCH 20/40] autonuma: alloc/free/init mm_autonuma

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
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 [at] redhat>
---
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;
atomic_set(&mm->mm_users, 1);
atomic_set(&mm->mm_count, 1);
init_rwsem(&mm->mmap_sem);
@@ -549,6 +551,8 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p)
return mm;
}

+ free_mm_autonuma(mm);
+out_free_mm:
free_mm(mm);
return NULL;
}
@@ -598,6 +602,7 @@ void __mmdrop(struct mm_struct *mm)
destroy_context(mm);
mmu_notifier_mm_destroy(mm);
check_mm(mm);
+ free_mm_autonuma(mm);
free_mm(mm);
}
EXPORT_SYMBOL_GPL(__mmdrop);
@@ -880,6 +885,7 @@ fail_nocontext:
* If init_new_context() failed, we cannot use mmput() to free the mm
* because it calls destroy_context()
*/
+ free_mm_autonuma(mm);
mm_free_pgd(mm);
free_mm(mm);
return NULL;
@@ -1702,6 +1708,7 @@ void __init proc_caches_init(void)
mm_cachep = kmem_cache_create("mm_struct",
sizeof(struct mm_struct), ARCH_MIN_MMSTRUCT_ALIGN,
SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK, NULL);
+ mm_autonuma_init();
vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC);
mmap_init();
nsproxy_cache_init();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

riel at redhat

Jun 29, 2012, 11:54 AM

Post #2 of 9 (114 views)
Permalink

Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma [In reply to]

On 06/28/2012 08:56 AM, 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
> 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 [at] redhat>

Same comments as before. A description of what the data
structure is used for and how would be good.

--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

konrad at darnok

Jun 29, 2012, 10:12 PM

Post #3 of 9 (114 views)
Permalink

Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma [In reply to]

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".

> 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 [at] redhat>
> ---
> 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?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

riel at redhat

Jul 1, 2012, 8:33 AM

Post #4 of 9 (109 views)
Permalink

Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma [In reply to]

On 06/28/2012 08:56 AM, Andrea Arcangeli wrote:

> 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;
> atomic_set(&mm->mm_users, 1);
> atomic_set(&mm->mm_count, 1);
> init_rwsem(&mm->mmap_sem);

I wonder if it would be possible to defer the allocation
of the mm_autonuma struct to knuma_scand, so short lived
processes never have to allocate and free the mm_autonuma
structure.

That way we only have a function call at exit time, and
the branch inside kfree that checks for a null pointer.

--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

aarcange at redhat

Jul 12, 2012, 11:08 AM

Post #5 of 9 (85 views)
Permalink

Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma [In reply to]

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 [at] redhat>
> > ---
> > 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 majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hannes at cmpxchg

Jul 12, 2012, 11:17 AM

Post #6 of 9 (90 views)
Permalink

Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma [In reply to]

On Thu, Jul 12, 2012 at 08:08:28PM +0200, Andrea Arcangeli wrote:
> 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.

UMA?

Single-node hardware?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

aarcange at redhat

Jul 12, 2012, 11:27 AM

Post #7 of 9 (85 views)
Permalink

Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma [In reply to]

Hi Rik,

On Sun, Jul 01, 2012 at 11:33:17AM -0400, Rik van Riel wrote:
> On 06/28/2012 08:56 AM, Andrea Arcangeli wrote:
>
> > 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;
> > atomic_set(&mm->mm_users, 1);
> > atomic_set(&mm->mm_count, 1);
> > init_rwsem(&mm->mmap_sem);
>
> I wonder if it would be possible to defer the allocation
> of the mm_autonuma struct to knuma_scand, so short lived
> processes never have to allocate and free the mm_autonuma
> structure.
>
> That way we only have a function call at exit time, and
> the branch inside kfree that checks for a null pointer.

It would be possible to convert them to prepare_mm/task_autonuma (the
mm side especially would be a branch once in a while) but it would
then become impossible to inherit the mm/task stats across
fork/clone. Right now the default is to reset them, but two sysfs
switches control that, and I wouldn't drop those until I've the time
to experiment how large kernel builds are affected by enabling the
stats inheritance. Right now kernel builds are unaffected because of
the default stat-resetting behavior and gcc too quick to be measured.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

cl at linux

Jul 13, 2012, 7:19 AM

Post #8 of 9 (77 views)
Permalink

Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma [In reply to]

On Thu, 12 Jul 2012, Johannes Weiner wrote:

> On Thu, Jul 12, 2012 at 08:08:28PM +0200, Andrea Arcangeli wrote:
> > 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.
>
> UMA?
>
> Single-node hardware?

Lets be simple and stay with non-NUMA.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

aarcange at redhat

Jul 14, 2012, 10:01 AM

Post #9 of 9 (76 views)
Permalink

Re: [PATCH 20/40] autonuma: alloc/free/init mm_autonuma [In reply to]

On Fri, Jul 13, 2012 at 09:19:06AM -0500, Christoph Lameter wrote:
> On Thu, 12 Jul 2012, Johannes Weiner wrote:
>
> > On Thu, Jul 12, 2012 at 08:08:28PM +0200, Andrea Arcangeli wrote:
> > > 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.
> >
> > UMA?
> >
> > Single-node hardware?
>
> Lets be simple and stay with non-NUMA.

Ok, I already corrected all occurrences.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads