Groups | Search | Server Info | Keyboard shortcuts | Login | Register


Groups > comp.os.linux.development.system > #405

Re: Howto - or - Feature Request - Process to Core locking

From John S <john.s43851955@gmail.com>
Newsgroups comp.os.linux.development.system
Subject Re: Howto - or - Feature Request - Process to Core locking
Date 2012-03-11 03:02 -0700
Organization http://groups.google.com
Message-ID <20606109.96.1331460176200.JavaMail.geo-discussion-forums@vbze11> (permalink)
References <25803231.739.1331157626474.JavaMail.geo-discussion-forums@vbbfv2> <alpine.DEB.2.00.1203080106060.19226@login01.caesar.elte.hu>

Show all headers | View raw


On Wednesday, March 7, 2012 7:17:57 PM UTC-5, Ersek, Laszlo wrote:
> On Wed, 7 Mar 2012, John S wrote:
> 
> >   We have tried cpuset and taskset to control affinity, but these
> > haven't fully resolved the issues.  The CPU scheduler will still
> > utilize an engine's core even though other cores are either unused or
> > have low useage.
> 
> I may be misunderstanding this: have you tried restricting everything else 
> to the complement CPU set?
> 
> (Eg. find the one script that's used to start "everything" in the system 
> when it reaches the preferred multi-user runlevel. (On Debian 
> /etc/init.d/rc seems possible.) Use "taskset -p complement_mask $$" in it; 
> it's children will inherit the affinity. Use "taskset mask_i engine i" 
> (like now) to start a given engine instance.)
> 
> Laszlo

    Will give it a try.  Thanks

    John

Back to comp.os.linux.development.system | Previous | NextPrevious in thread | Find similar


Thread

Howto - or - Feature Request - Process to Core locking John S <john.s43851955@gmail.com> - 2012-03-07 14:00 -0800
  Re: Howto - or - Feature Request - Process to Core locking "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-03-08 01:17 +0100
    Re: Howto - or - Feature Request - Process to Core locking John S <john.s43851955@gmail.com> - 2012-03-11 03:02 -0700

csiph-web