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

Groups > linux.debian.user > #167872 > unrolled thread

Can Debian do multi-core "MY WAY"?

Back to article view | Back to linux.debian.user

Contents

  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

#167872 — Can Debian do multi-core "MY WAY"?

I date from era when when "memory banks" were switched via 
contents of a I/O port ;/
Anyone remember era when 8085 was "state of the art" ;/

I envision
   core A using memory range X
   core B using memory range Z

My individual tasks could be handled by a 2MHz Z80

Can Debian do it on GHz machine?

[toc] | [next] | [standalone]

#167873

Richard Owlett writes:
> Anyone remember era when 8085 was "state of the art" ;/

I remember when the 8080 was "state of the art".

> I envision
>  core A using memory range X
>  core B using memory range Z

> My individual tasks could be handled by a 2MHz Z80

> Can Debian do it on GHz machine?

That's low-level kernel hacking.

-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#167877

On Saturday 14 May 2016 13:42:51 John Hasler wrote:

> Richard Owlett writes:
> > Anyone remember era when 8085 was "state of the art" ;/
>
> I remember when the 8080 was "state of the art".
>
> > I envision
> >  core A using memory range X
> >  core B using memory range Z
> >
> > My individual tasks could be handled by a 2MHz Z80
> >
> > Can Debian do it on GHz machine?
>
> That's low-level kernel hacking.

And you can download a pre-hacked version based on wheezy that can run 
machinery with sub-micron accuracy, far better than the average machine 
can do, as its subject to thermals etc that limit it to perhaps a 
thousandth of an inch in everyday use. From linuxcnc.org today and 
everyday.  Free every day.  I have 4 copies of it running here.  On the 
right board and cpu, this software can send a step pulse to a stepper 
motor driver every 25 microseconds.  Thats 40 kilohertz, not the stepper  
motors top speed, so if you really want to move fast, a 90 dollar card 
can take you to the limits of the opto-isolaters in those drivers at 
somewhere above 200 kilohertz.  Using that card allows one to be a whole 
lot less picky about the board and cpu.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#167874

On 14/05/16 18:31, Richard Owlett wrote:
> I envision
>    core A using memory range X
>    core B using memory range Z
>
> My individual tasks could be handled by a 2MHz Z80
>
> Can Debian do it on GHz machine?

Maybe.

Debian (and the Linux kernel) has a bewildering array of tools and 
options that *might* be applicable to the tasks you're carrying out. 
You'd need to tell us at least a little bit more about what you want to 
do. Obvious questions to ask would include:

* What kind of processor are you intending to run this on?

* Are you addressing peripheral devices or just system RAM?

* Is the requirement for the different tasks to be running on different 
physical cores absolute?

[toc] | [prev] | [next] | [standalone]

#167875

On Saturday 14 May 2016 13:31:28 Richard Owlett wrote:

> I date from era when when "memory banks" were switched via
> contents of a I/O port ;/
> Anyone remember era when 8085 was "state of the art" ;/

How about building a tv production tool out of an RCA 1802?  There was a 
time when that puppy was state of the art.

> I envision
>    core A using memory range X
>    core B using memory range Z
>
> My individual tasks could be handled by a 2MHz Z80
>
> Can Debian do it on GHz machine?


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#167879

Gene Heskett writes:
> How about building a tv production tool out of an RCA 1802?  There was
> a time when that puppy was state of the art.

Yes.  I wrote applications for it in hex, helped design a single board
computer using it, and helped write an 8 bit version of FORTH for it (it
was eminently suited for the task).
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#167876

On Sat, 14 May 2016 12:31:28 -0500
Richard Owlett <rowlett@cloud85.net> wrote:

> I date from era when when "memory banks" were switched via 
> contents of a I/O port ;/
> Anyone remember era when 8085 was "state of the art" ;/
> 
> I envision
>    core A using memory range X
>    core B using memory range Z
> 
> My individual tasks could be handled by a 2MHz Z80
> 
> Can Debian do it on GHz machine?
> 
> 
> 

It isn't clear why you would need user control at this level, why the
processor and memory allocation systems of the OS will not meet your
needs.

The last time I saw this done was in driving a Solidisk sideways RAM
board on the BBC Micro, and that was done only because the processor
had a very limited addressing capability. It was done very badly...

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#167880

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 ;/
> Anyone remember era when 8085 was "state of the art" ;/
> 
> 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

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlc3j6QACgkQBcgs9XrR2kYjngCZAe7J7DfWSa87aRlA1vmhNCN+
Nq4An1WjmIBDCmJvahR2j5ITl1965uLu
=/ElI
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#167882

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 .

[toc] | [prev] | [next] | [standalone]

#167883

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 ;/
>> Anyone remember era when 8085 was "state of the art" ;/
>>
>> 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 ;]

[2] gives valuable insight in how I should partition my disk when 
moving from Windows to Debian. It gives me some insight anyway.

Thanks

[toc] | [prev] | [next] | [standalone]

#167884

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...

> >>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 :-)

> [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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web