On Feb 28, 2011, at 4:46 PM, David Singleton wrote:
>> So: binding + pinning = binding (as long as you can ensure that the binding
>> + pinning was atomic!).
>
> Atomicity should not be a problem. Setting memory binding and pinning (eg
> mlock) are
> both actions on vma properties. They
On 03/01/2011 08:44 AM, Jeff Squyres wrote:
On Feb 28, 2011, at 4:39 PM, Brice Goglin wrote:
So: binding + pinning = binding (as long as you can ensure that the binding +
pinning was atomic!).
If the application swaps for real, do you really care about NUMA
locality ? It seems to me that
On 03/01/2011 08:30 AM, Jeff Squyres wrote:
So: binding + pinning = binding (as long as you can ensure that the binding +
pinning was atomic!).
Atomicity should not be a problem. Setting memory binding and pinning (eg
mlock) are
both actions on vma properties. They would normally happen
On Feb 28, 2011, at 4:39 PM, Brice Goglin wrote:
>> So: binding + pinning = binding (as long as you can ensure that the binding
>> + pinning was atomic!).
>
> If the application swaps for real, do you really care about NUMA
> locality ? It seems to me that the overhead of accessing distant NUMA
Le 28/02/2011 22:30, Jeff Squyres a écrit :
> This is really a pretty terrible statement we (the Linux community) are
> making: it's all about manycore these days, and a direct consequence of that
> is that it's all about NUMA. So you should bind your memory.
>
> But that may not be enough.
On 03/01/2011 08:01 AM, Jeff Squyres wrote:
On Feb 28, 2011, at 3:47 PM, David Singleton wrote:
I dont think you can avoid the problem. Unless it has changed very recently, Linux
swapin_readahead is the main culprit in messing with NUMA locality on that platform.
Faulting a single page
On Feb 28, 2011, at 4:18 PM, Brice Goglin wrote:
> Ah good point! So Jeff has to hope that pages of different processes
> won't be highly mixed in the swap partition, good luck :)
This is really a pretty terrible statement we (the Linux community) are making:
it's all about manycore these days,
Le 28/02/2011 21:47, David Singleton a écrit :
> I dont think you can avoid the problem. Unless it has changed very
> recently, Linux swapin_readahead is the main culprit in messing with
> NUMA locality on that platform. Faulting a single page causes 8 or 16
> or whatever contiguous pages to be
Le 28/02/2011 22:04, Jeff Squyres a écrit :
> That being said, someone cited on this list a long time ago that running the
> hwloc detection on very large machines (e.g., SGI machines with 1000+ cores)
> takes on the order of seconds (because it traverses /sys, etc.). So if you
> want your
Guy Streeter, le Mon 28 Feb 2011 21:52:47 +0100, a écrit :
> I was considering the design of an administration tool in python, and my
> original idea was to have each module that needs the topology object create
> its own. This means that different parts of the same program (but possibly
> in
On Feb 28, 2011, at 3:52 PM, Guy Streeter wrote:
> I was considering the design of an administration tool in python, and my
> original idea was to have each module that needs the topology object create
> its own. This means that different parts of the same program (but possibly in
> different
On Feb 28, 2011, at 3:47 PM, David Singleton wrote:
> I dont think you can avoid the problem. Unless it has changed very recently,
> Linux swapin_readahead is the main culprit in messing with NUMA locality on
> that platform. Faulting a single page causes 8 or 16 or whatever contiguous
>
I was considering the design of an administration tool in python, and my
original idea was to have each module that needs the topology object create
its own. This means that different parts of the same program (but possibly in
different threads) would call init and load on their own topology
On 03/01/2011 05:51 AM, Jeff Squyres wrote:
On Feb 28, 2011, at 12:24 PM, Bernd Kallies wrote:
1. I have no reason to doubt this person, but was wondering if someone could
confirm this (for Linux).
set_mempolicy(2) of recent 2.6 kernels says:
Process policy is not remembered if the page is
Le 28/02/2011 21:35, Jeff Squyres a écrit :
> On Feb 28, 2011, at 3:31 PM, Brice Goglin wrote:
>
>
> That would seem to imply that I should always hwloc_set_area_membind() if
> I want it to persist beyond any potential future swapping.
>
>> The kernel only looks at the
Le 28/02/2011 21:18, Jeff Squyres a écrit :
> On Feb 28, 2011, at 2:02 PM, Samuel Thibault wrote:
>
>
>>> That would seem to imply that I should always hwloc_set_area_membind() if I
>>> want it to persist beyond any potential future swapping.
>>>
>> I guess that could be right, but it
Jeff Squyres, le Mon 28 Feb 2011 21:18:52 +0100, a écrit :
> On Feb 28, 2011, at 2:02 PM, Samuel Thibault wrote:
>
> >> That would seem to imply that I should always hwloc_set_area_membind() if
> >> I want it to persist beyond any potential future swapping.
> >
> > I guess that could be right,
Jeff Squyres, le Mon 28 Feb 2011 19:54:27 +0100, a écrit :
> On Feb 28, 2011, at 12:24 PM, Bernd Kallies wrote:
>
> >> 1. I have no reason to doubt this person, but was wondering if someone
> >> could confirm this (for Linux).
> >
> > set_mempolicy(2) of recent 2.6 kernels says:
> > Process
On Mon, 2011-02-28 at 11:51 -0500, Jeff Squyres wrote:
> Someone just made a fairly disturbing statement to me in an Open MPI bug
> ticket: if you bind some memory to a particular NUMA node, and that memory
> later gets paged out, then it loses its memory binding information -- meaning
> that
Le 28/02/2011 17:51, Jeff Squyres a écrit :
> Someone just made a fairly disturbing statement to me in an Open MPI bug
> ticket: if you bind some memory to a particular NUMA node, and that memory
> later gets paged out, then it loses its memory binding information -- meaning
> that it can
Someone just made a fairly disturbing statement to me in an Open MPI bug
ticket: if you bind some memory to a particular NUMA node, and that memory
later gets paged out, then it loses its memory binding information -- meaning
that it can effectively get paged back in at any physical location.
21 matches
Mail list logo
