Groups | Search | Server Info | Keyboard shortcuts | Login | Register
Groups > comp.os.linux.development.system > #405
| 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> |
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 | Next — Previous in thread | Find similar
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