Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #167882

Re: Can Debian do multi-core "MY WAY"?

Show all headers | View raw

On 5/15/2016 9:27 AM, Henrique de Moraes Holschuh wrote:
> On Sun, 15 May 2016, Richard Owlett wrote:
>> On 5/14/2016 3:50 PM, tomas@tuxteam.de wrote:
>>> On Sat, May 14, 2016 at 12:31:28PM -0500, Richard Owlett wrote:
>>>> I date from era when when "memory banks" were switched via contents
>>>> of a I/O port ;/
>
> Reminds me of the MSX memory mapper, and MSX paged slot selection...

About the same period. In late 70's I had a supervisor who would 
do things just because people told him he couldn't. He set up his 
KIM-1 to access several megabytes.

>
>>>> I envision
>>>>    core A using memory range X
>>>>    core B using memory range Z
>>>
>>> What you are describing is called "non uniform memory access" aka
>>> NUMA [1] these days and yes, the Linux kernel takes into account
>>> that different parts of memory have different "distances" to each
>>> processor (e.g. by assigning process "affinities" to each CPU.
>>>
>>> To a lesser extent, CPU caches do this too.
>>>
>>> This is'nt surprising, since CPU bandwidth has outrun memory
>>> bandwith significantly across the last 20-30 years. If a CPU
>>> had to wait for every byte to arrive from main memory, they'd
>>> be slower by a huge amount [2].
>>>
>>> So in some way the answer is; yes, your PC and your OS is probably
>>> doing it already :-)
>>>
>>> regards
>>>
>>> [1] https://en.wikipedia.org/wiki/Non-Uniform_Memory_Access
>>> [2] http://gameprogrammingpatterns.com/data-locality.html
>>>
>>
>> [1] Tells me I almost asked the question I thought I intended to ask ;/
>> I'm a consumer of programs but not a programmer.
>> A closer approximation to a correct _question_ might be "Can I as user tell
>> OS to run program *1* and _only_ program *1* on core A which has exclusive
>> use of memory range X? Everything else can use core B and memory range Y."
>> [I'll probably have a better description after hitting send ;]
>
> Yes, you can.  We call that "cpu pinning".  But the way it works for what
> you want is that you need to pin everything else *out* of CPU A (including
> interrupts), and pin the process (or interrupt, etc) you want to CPU A.  And
> that's somewhat annoying to do.
>
> In Debian (*nix, really), one usually doesn't have to bother with main
> memory affinity unless one is running HPC workloads on a NUMA box.  SMP and
> SMP+SMT boxes (i.e. non-NUMA) only care about cache-locality effects.  And
> by the time you're bothering with cache affinity beyond what the kernel will
> do automatically when you pin stuff to CPUs, you need to know about enough
> low-level details about the platform, firmware and kernel, that it doesn't
> make sense to bother even trying to explain in this ML.
>
> Package "hwloc" helps with auto-detecting cache/node/processor topology and
> locality, and has utilities to pin stuff to nodes, etc.
>
> HPC (high-performance computing) tutorials and guides often explain a lot of
> the underlying stuff, you might want to look for them.  High-throughput IO
> (such as gigabit/10-gigabit software-based routing on many-core machines) is
> another application that requires one to bother with these details (in this
> specific case: kernel interrupt pinning, hardware capabilities for interrupt
> routing/MSI-X, PCIe bus topology, etc).  Look for papers on these subjects,
> they're fun to read and explain a lot of low level details.
>
> Most often, it is enough to pin the process to CPU A, change its scheduling
> priority to a very high one, and let the other processes move freely among
> CPUs (the default).  If the process in CPU A is using the CPU all the time,
> the task scheduler will keep everything else (but itself and some
> interrupts) away from CPU A.
>
> But really, unless your problem is actually *jitter* or any hard-realtime
> tight semanthics, or high-throughput HPC workloads, you are unlikely to need
> to mess with any of these.
>
> nd if you are going to do tight hard-realtime, or you are worried about
> sub-millisecond jitter, Debian is not likely to be the right tool for the
> job.  We do high-througput IO and HPC workloads just fine, though :-)

You just unraveled a tangled thought process. I had a poor 
solution to an ill defined problem. But I will chase down the 
reference hints you gave.


>
>> [2] gives valuable insight in how I should partition my disk when moving
>> from Windows to Debian. It gives me some insight anyway.
>
> Don't try to get everything right the first time.  Plan for a few
> reinstalls as you learn, and it will be much easier.
>

I was doing so many reinstalls I learned the benefits of 
preseed.gfg .

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Can Debian do multi-core "MY WAY"? Richard Owlett <rowlett@cloud85.net> - 2016-05-14 19:40 +0200
  Re: Can Debian do multi-core "MY WAY"? John Hasler <jhasler@newsguy.com> - 2016-05-14 19:50 +0200
    Re: Can Debian do multi-core "MY WAY"? Gene Heskett <gheskett@shentel.net> - 2016-05-14 20:50 +0200
  Re: Can Debian do multi-core "MY WAY"? Martin Read <zen75502@zen.co.uk> - 2016-05-14 20:20 +0200
  Re: Can Debian do multi-core "MY WAY"? Gene Heskett <gheskett@shentel.net> - 2016-05-14 20:30 +0200
    Re: Can Debian do multi-core "MY WAY"? John Hasler <jhasler@newsguy.com> - 2016-05-14 21:40 +0200
  Re: Can Debian do multi-core "MY WAY"? Joe <joe@jretrading.com> - 2016-05-14 20:30 +0200
  Re: Can Debian do multi-core "MY WAY"? <tomas@tuxteam.de> - 2016-05-14 23:00 +0200
    Re: Can Debian do multi-core "MY WAY"? Richard Owlett <rowlett@cloud85.net> - 2016-05-16 04:20 +0200
    Re: Can Debian do multi-core "MY WAY"? Richard Owlett <rowlett@cloud85.net> - 2016-05-16 04:20 +0200
      Re: Can Debian do multi-core "MY WAY"? Henrique de Moraes Holschuh <hmh@debian.org> - 2016-05-16 04:20 +0200

csiph-web