All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Andi Kleen <andi@firstfloor.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Lee@firstfloor.org, Schermerh@firstfloor.org
Subject: Re: [rfc] forked kernel task and mm structures imbalanced on NUMA
Date: Tue, 1 Jun 2010 18:20:25 +0200	[thread overview]
Message-ID: <20100601162024.GC30556@basil.fritz.box> (raw)
In-Reply-To: <20100601155943.GA9453@laptop>

On Wed, Jun 02, 2010 at 01:59:43AM +1000, Nick Piggin wrote:
> On Tue, Jun 01, 2010 at 05:48:10PM +0200, Andi Kleen wrote:
> > Nick Piggin <npiggin@suse.de> writes:
> > 
> > > This isn't really a new problem, and I don't know how important it is,
> > > but I recently came across it again when doing some aim7 testing with
> > > huge numbers of tasks.
> > 
> > Seems reasonable. Of course you need to at least 
> > save/restore the old CPU policy, and use a subset of it.
> 
> The mpolicy? My patch does that (mpol_prefer_cpu_start/end). The real
> problem is that it can actually violate the parent's mempolicy. For
> example MPOL_BIND and cpus_allowed set on a node outside the mempolicy.

I don't see where you store 'old', but maybe I missed it.

> > slightly more difficult. The advantage would be that on multiple
> > migrations it would follow. And it would be a bit slower for
> > the initial case.
> 
> Migrate what on touch? Talking mainly about kernel memory structures,
> task_struct, mm, vmas, page tables, kernel stack, etc.

Migrate task_struct, mm, vmas, page tables, kernel stack
on reasonable touch. As long as they are not shared it shouldn't
be too difficult.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Andi Kleen <andi@firstfloor.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Lee@firstfloor.org, Schermerh@firstfloor.org
Subject: Re: [rfc] forked kernel task and mm structures imbalanced on NUMA
Date: Tue, 1 Jun 2010 18:20:25 +0200	[thread overview]
Message-ID: <20100601162024.GC30556@basil.fritz.box> (raw)
In-Reply-To: <20100601155943.GA9453@laptop>

On Wed, Jun 02, 2010 at 01:59:43AM +1000, Nick Piggin wrote:
> On Tue, Jun 01, 2010 at 05:48:10PM +0200, Andi Kleen wrote:
> > Nick Piggin <npiggin@suse.de> writes:
> > 
> > > This isn't really a new problem, and I don't know how important it is,
> > > but I recently came across it again when doing some aim7 testing with
> > > huge numbers of tasks.
> > 
> > Seems reasonable. Of course you need to at least 
> > save/restore the old CPU policy, and use a subset of it.
> 
> The mpolicy? My patch does that (mpol_prefer_cpu_start/end). The real
> problem is that it can actually violate the parent's mempolicy. For
> example MPOL_BIND and cpus_allowed set on a node outside the mempolicy.

I don't see where you store 'old', but maybe I missed it.

> > slightly more difficult. The advantage would be that on multiple
> > migrations it would follow. And it would be a bit slower for
> > the initial case.
> 
> Migrate what on touch? Talking mainly about kernel memory structures,
> task_struct, mm, vmas, page tables, kernel stack, etc.

Migrate task_struct, mm, vmas, page tables, kernel stack
on reasonable touch. As long as they are not shared it shouldn't
be too difficult.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-06-01 16:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-01  7:33 [rfc] forked kernel task and mm structures imbalanced on NUMA Nick Piggin
2010-06-01  7:33 ` Nick Piggin
2010-06-01  8:16 ` Peter Zijlstra
2010-06-01  8:16   ` Peter Zijlstra
2010-06-01  8:41   ` Nick Piggin
2010-06-01  8:41     ` Nick Piggin
2010-06-01  9:05     ` Peter Zijlstra
2010-06-01  9:05       ` Peter Zijlstra
2010-06-01  8:49   ` Peter Zijlstra
2010-06-01  8:49     ` Peter Zijlstra
2010-06-01 15:48 ` Andi Kleen
2010-06-01 15:48   ` Andi Kleen
2010-06-01 15:59   ` Nick Piggin
2010-06-01 15:59     ` Nick Piggin
2010-06-01 16:20     ` Andi Kleen [this message]
2010-06-01 16:20       ` Andi Kleen
2010-06-01 16:31       ` Nick Piggin
2010-06-01 16:31         ` Nick Piggin
2010-06-01 16:00 ` Peter Zijlstra
2010-06-01 16:00   ` Peter Zijlstra
2010-06-01 16:02   ` Peter Zijlstra
2010-06-01 16:02     ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100601162024.GC30556@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=Lee@firstfloor.org \
    --cc=Schermerh@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=npiggin@suse.de \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.