[squeak-dev] Processor affinity for VM's?

gettimothy gettimothy at zoho.com
Thu Sep 12 13:48:40 UTC 2019


Hi David,

Thank you. 

The project currently relies heavily on OSProcess and Command Shell for some tasks and I look forward to learning and integrating RemoteTask into it.
The hub and spoke model you suggest will fit the bill nicely too.

On Linux, it is far easier to use CommandShell for linux directory and file handling. 


Thank you to all others who contributed to this discussion. Much appreciated.

t





---- On Wed, 11 Sep 2019 20:51:23 -0400 David T. Lewis <mailto:lewis at mail.msen.com> wrote ----


Thanks for the pointers and plugs :-)

A relevant part of OSProcess/CommandShell is RemoteTask (http://wiki.squeak.org/squeak/6176).

Cog/Spur VM users (i.e. everybody reading this) will need to redirect standard
input from /dev/null in order to work around a bug in the standard input
processing for those VMs, so e.g. "$ squeak myimage < /dev/null & "  when run
from a command line.

This does a reasonable job of coarse-grained multiprocessing when you want to
start a bunch of worker images from a single parent image, collecting output
frome the forked images in their parent image.

Note that processor affinity is not an issue. Just create some number of
forked images less than the number of cores, and your operating system will
do a good job of handing the CPU assignment.

Dave

On Wed, Sep 11, 2019 at 07:13:24PM -0500, Chris Muller wrote:
> Be sure to grab Dave Lewis' CommandLine package too, it has #forkSqueak: I
> think, which makes use of Linux's ability to share unchanged memory with
> other processes.
> 
> Another option for larger-grained tasks, MaClientServer has a
> NetworkOrchestra, an object you can configure and then #launch -- which
> uses OSProcess to keep a specified number of worker images running to
> complete a large task.  It's utilized by its test-suite.
> 
> 
> On Wed, Sep 11, 2019 at 4:22 PM gettimothy via Squeak-dev <
> mailto:squeak-dev at lists.squeakfoundation.org> wrote:
> 
> > Tim
> >
> > Thanks you very much.
> >
> > I have OSProcess installed in my image for the project I have in mind and
> > I will do just that.
> >
> > cheers.
> >
> > t
> >
> > ---- On Wed, 11 Sep 2019 17:11:00 -0400 *tim Rowledge <mailto:tim at rowledge.org
> > <mailto:tim at rowledge.org>>* wrote ----
> >
> > Load OSProcess. Try out the image spawning/forking tools. Works really
> > well on a Raspberry Pi so I suspect it would be even faster on bigger
> > machines.
> >
> > > On 2019-09-11, at 1:59 PM, Phil B <mailto:pbpublist at gmail.com> wrote:
> > >
> > > The difference is that the JVM inherently supports multi-core at via
> > threads in a single VM instance while the Squeak/Cog VM's don't as they
> > only support 'green' threads on a single logical core. So for Cog you'd use
> > the core affinity tools provided at the OS level to assign affinity at the
> > instance level. That said, I'd suggest measuring performance with and
> > without processor affinity set as you might find it doesn't provide enough
> > benefit to be worth the hassle depending on the load characteristics.
> > >
> > > On Wed, Sep 11, 2019 at 4:27 PM gettimothy via Squeak-dev <
> > mailto:squeak-dev at lists.squeakfoundation.org> wrote:
> > > Hi All,
> > >
> > > I have a large processing task to do that I would like to divvy up among
> > separate copies of an image running on their own VM instance running on a
> > virtual core.
> > >
> > > Processor is a Ryzen7 with 16 virtual cores.
> > > I figure 1 for me and 15 for separate Cog VM's
> > >
> > > I remember from decades that the JVM had a processor affinity switch.
> > >
> > >
> > > Is there such a thing in Cog?
> > >
> > > Thanks in advance.
> > >
> > > tty
> > >
> >
> > tim
> > --
> > tim Rowledge; mailto:tim at rowledge.org; http://www.rowledge.org/tim
> > Strange OpCodes: RLBM: Ruin Logic Board Multiple
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190912/2d605996/attachment.html>


More information about the Squeak-dev mailing list