Re: AMD64 NUMA-awareness?
From: Scott Long (scottl_at_samsco.org)
Date: 05/19/05
- Previous message: Jung-uk Kim: "AMD64 NUMA-awareness?"
- In reply to: Jung-uk Kim: "AMD64 NUMA-awareness?"
- Next in thread: Jeff Roberson: "Re: AMD64 NUMA-awareness?"
- Reply: Jeff Roberson: "Re: AMD64 NUMA-awareness?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 19 May 2005 12:38:15 -0600 To: Jung-uk Kim <jkim@niksun.com>
Jung-uk Kim wrote:
> ULE scheduler paper
> (http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/roberson.html)
> says:
>
> 'SMT introduces a concept of non-uniform processors into ULE which
> could be extended to support NUMA. The concept of expressing the
> penalty for migration through the use of separate queues could be
> further developed to include a local and global load-balancing
> policy. At the time of this writing, however, FreeBSD does not
> support any true NUMA capable machines and so this is left until such
> time that it does.'
>
> I am not sure about the meaning of 'true NUMA capable machines' but
> AMD64 is ccNUMA unless I am completely mistaken, and FreeBSD/amd64 is
> well-supported. Even multicore processors are available now and
> Intel is going to release dual-core processors with HTT to make
> matters worse.
>
Even HTT by itself presents some interesting scheduling challenges that
need to be accounted for.
> Is there anybody working on this?
Jeff stated recently that both ULE and 4BSD have some very primitive
awareness of topology, but that much more work is needed. NUMA would
also benefit from the UMA memory allocator understanding memory topology
and working with the scheduler to keep processes on CPUs that are
closest to their memory. Unfortunately, there doesn't appear to be
much work going on, so if anyone is interested, it's a great project and
I encourage all to help.
Scott
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Jung-uk Kim: "AMD64 NUMA-awareness?"
- In reply to: Jung-uk Kim: "AMD64 NUMA-awareness?"
- Next in thread: Jeff Roberson: "Re: AMD64 NUMA-awareness?"
- Reply: Jeff Roberson: "Re: AMD64 NUMA-awareness?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Migrate pages from a ccNUMA node to another
... We are left with Non Uniform Memory Architectures. ... You can make use of the
forthcoming NUMA APIs to set up your NUMA environment: ... (e.g. it is a reference benchmark)
... Page migration tries to help you out in these situations. ... (Linux-Kernel) - Re: NUMA API - wish list
... > resources from some NUMA domains to others, ... all available memory
bandwidth and the best average memory latency. ... require to go all the way to a full workload
manager ... But NUMA knowledge is purely for optimization. ... (Linux-Kernel) - Re: [OOPS] 2.6.9-rc4, dual Opteron, NUMA, 8GB
... >> of there only being one NUMA zone. ... > It also works with NUMA
and 8GB if I balance the memory between the two ... Linux has no such limitations
in the NUMA code, ... (Linux-Kernel) - Re: [rfc] balance-on-fork NUMA placement
... course will leave the memory behind...), but it does give a bit more ... We
certainly used to copy all page tables on fork. ... the NUMA scheduler, and every
time we decide it's a bad idea. ... cycle slower, not faster, so exec is generally a much
better time to do ... (Linux-Kernel) - Re: PG_zero
... problem twice as much memory as I do to get the same boost. ... > Remember
it's not global at all on the larger systems, since they're NUMA. ... higher latency of
the buddy allocator, this is why the per-cpu lists ... The buffering is really a "refill",
... (Linux-Kernel)