*Non-Uniform Memory Access* (*NUMA*) is a computer
memory<
http://en.wikipedia.org/wiki/Computer_storage> design
used in multiprocessing <
http://en.wikipedia.org/wiki/Multiprocessing>,
where the memory access time depends on the memory location relative to a
processor. Under NUMA, a processor can access its own local memory faster
than non-local memory (memory local to another processor or memory shared
between processors).
So it is not about giving a process its own memory so much as taking a
processor with its own memory and allowing it to share. in a manner that is
efficient the wiki on it is really good.
http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access my experience with
NUMA was if it was disabled you had a huge performance hit with an
exception for multiple single threaded tasks as opposed to multiple
threaded tasks that may use multiple cores/processors and access a shared
pool.
NUMA is only relevant when you are dealing with multiple processors really
as single processors even with a large number of cores use the same
interconnect to memory.
On Mon, Jun 3, 2013 at 1:27 PM, Nadim Hoque <
nadimhoque@gmail.com> wrote:
> If i recall AMD started doing NUMA which each core gets a dedicated amount
> of memory that is tied to it. The plus side is that when the core needs
> something in its own memory region it does not need to put the request in
> the queue like in non-numa and gets it faster. The down side is if it needs
> data in a memory region that belongs to another core it will take longer
> since it essentially has to ask that core for that data. In non-numa
> architecture the entire memory space is allocated to all cores which means
> that each core can access memory with out asking another for data. The
> problem with this is that all memory requests is put in a queue and the
> core has to wait until the memory controller is able to process the
> request. For many core and lot of memory systems you are mostly better off
> with NUMA. Correct me if I am wrong though.
>
>
> On Mon, Jun 3, 2013 at 7:25 AM, Stephen <cryptworks@gmail.com> wrote:
>
>> Not really, Dual channel mode means you can read and write to both Banks
>> of memory at the same time (aka Ganged). Single Channel means you treat all
>> ram as a single bank reading and writing to one and then the other. think
>> Raid 0 vs JBOD if that helps.
>>
>> I personally have had 0 issue with greater than 4 GB of ram in a machine
>> with Linux and a 64 bit kernel. and i have worked with multiple
>> distributions over the years back and forth.
>>
>> the main difference between Intel and AMD i have seen since the core i
>> series CPUs were released is that AMD still has wicked fast memory
>> performance but Intel wins most everything else.
>>
>> If you have multiple processors you will want to look for numa. This
>> allows inter processor communication for ram access.
>>
>> It should not matter if you are running ganged or unchanged your is
>> should see all ram installed with the exception of the PCI/pcie/chip set
>> nibbling 100 to 700mb for doing its thing in consumer chipsets.
>> On Mon, Jun 3, 2013 at 6:36 AM, keith smith <klsmith2020@yahoo.com>wrote:
>>
>>>
>>> I found this in an on-line discussion:
>>>
>>> Ganged = dual channel mode for ram. All cores get access to 100% of the
>>> ram.
>>>
>>> unganged = single channel. Each core gets access to a stick of ram.
>>>
>>> Is this correct?
>>>
>>>
>>> ------------------------
>>> Keith Smith
>>>
>>> --- On *Mon, 6/3/13, Nathan England <nathan@nmecs.com>* wrote:
>>>
>>>
>>> From: Nathan England <nathan@nmecs.com>
>>> Subject: Re: AMD vs Intel memory managemement
>>> To: "Main PLUG discussion list" <plug-discuss@lists.phxlinux.org>
>>> Date: Monday, June 3, 2013, 1:35 AM
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yeah, it's a wonderful thing AMD calls "unganged" mode. I have 8 GB of
>>> ram in my server and the motherboard has enabled "unganged" mode to be more
>>> efficient. CentOS only recognizes 5.8 GB of ram and I cannot turn off
>>> unganged mode.
>>>
>>>
>>>
>>> I love it...
>>>
>>>
>>>
>>> </sarcasm>
>>>
>>>
>>>
>>>
>>> On Sunday, June 02, 2013 17:46:19 keith smith wrote:
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>> After that great thread on 32bit vs 64bit, I was wondering if it would
>>> be beneficial at this point to drill down to the CPU level : AMD vs Intel.
>>>
>>> We had a great thread a while ago the AMD CPU, however I do not think
>>> that thread covered memory management.
>>>
>>> I almost went for an AMD CPU this go around (I have a couple from prior
>>> purchases), however after hearing that AMD does some weird memory
>>> management at the core level, assigning memory by the bank to each core, I
>>> thought I would go with an Intel CPU.
>>>
>>> If I understand this correctly, It sounds like under some or most
>>> circumstances the server will lose a portion of the total memory because
>>> under AMD RAM is assigned at the core level and bank level. I assume Intel
>>> uses memory as a pool. Need memory just grab some until it is gone.
>>>
>>> Any thoughts on this?
>>>
>>> Thanks!
>>>
>>> ------------------------
>>> Keith Smith
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Nathan England
>>>
>>>
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> NME Computer Services http://www.nmecs.com
>>>
>>> Nathan England (nathan@nmecs.com)
>>>
>>> Systems Administration / Web Application Development
>>>
>>> Information Security Consulting
>>>
>>> (480) 559.9681
>>>
>>>
>>>
>>> -----Inline Attachment Follows-----
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org<http://mc/compose?to=PLUG-discuss@lists.phxlinux.org>
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>
>>
>>
>> --
>> A mouse trap, placed on top of your alarm clock, will prevent you from
>> rolling over and going back to sleep after you hit the snooze button.
>>
>> Stephen
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
>
>
> --
> Nadim Hoque
> Systems Support Analyst
> Engineering Technical Services
> Arizona State University
> Cell: 480-518-6235
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
--
A mouse trap, placed on top of your alarm clock, will prevent you from
rolling over and going back to sleep after you hit the snooze button.
Stephen
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)