Re: posix osiSpawnDetachedProcess inherits scheduling policy + priority

[Till Straumann <strauman@slac.stanford.edu>]

On 11/27/2012 04:34 PM, Hill, Jeff wrote:
> > I doubt if there are many users of osiSpawnDetachedProcess() other than the
> > caRepeater, but I wouldn't want to break any that do exist which need to
> > inherit the SCHED_FIFO setting.
> I'm ok with adding a new function called osiSpawnDefaultAttributeDetachedProcess() for use with starting the ca repeater, and documenting also that the intent of osiSpawnDetachedProcess will be to create a process inheriting most of the calling processes attributes.
I have said most I wanted to say in my last post.
Let me just add here that passing process attributes is probably
OK. However, the scheduling policy and priority are attributes of
the particular thread which calls osiSpawnDetachedProcess() and
they are inherited by the entire child process.
I don't think this is appropriate. The detached process should be
created using SCHED_OTHER. Another problem with the current
scheme I have is that the potentially expensive 'fork' and 'exec' are
executing with a real-time priority.

Hard to measure exactly but getrusage() reports a loop of 1000
attempts to osiSpawnDetachedProcess("/bin/true") (1GHz pentium M running 
linux
with RT_PREEMPT) to use rougly 0.55 seconds ('system time'), i.e.,
500us per call. Not good.

IMO 'osiSpawnDetachedProcess()' should be fixed so that the calling
thread temporarily switches to SCHED_OTHER until the call returns
(or simply creates a new thread with SCHED_OTHER policy which then
forks).

Till
> Jeff
>
> > -----Original Message-----
> > From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> > On Behalf Of Andrew Johnson
> > Sent: Tuesday, November 27, 2012 2:19 PM
> > To: tech-talk@aps.anl.gov
> > Subject: Re: posix osiSpawnDetachedProcess inherits scheduling policy +
> > priority
> >
> > Hi Till,
> >
> > On 2012-11-26 Till Straumann wrote:
> > > The current implementation of posix/osiSpawnDetachedProcess()
> > > basically just forks and execs. The new process inherits the
> > > scheduling policy and priority of whoever called spawnDetachedProcess().
> > >
> > > This means e.g., that a caRepeater spawned by a "real-time enabled"
> > > IOC application executes under SCHED_FIFO with priority 51.
> > >
> > > Not sure this is a good thing. IMO osiSpawnDetachedProcess()
> > > should be fixed so that the new process starts out with SCHED_OTHER.
> > I doubt if there are many users of osiSpawnDetachedProcess() other than the
> > caRepeater, but I wouldn't want to break any that do exist which need to
> > inherit the SCHED_FIFO setting.  If the child process of the fork() were to
> > change to SCHED_OTHER before calling execlp() the new program might not have
> > the privilege necessary to switch back — is that correct?
> >
> > Personally I would solve the problem of having an RT-scheduled caRepeater by
> > ensuring that caRepeater always gets started when the system comes up before
> > the IOCs get run, say from an /etc/init.d script.
> >
> > We could add another API that switches to SCHED_OTHER before the execlp()
> > and
> > use that when starting the caRepeater, but I'm not sure about portability.
> >
> > What do you think?
> >
> > - Andrew
> > --
> > Computer science is as much about computers as astronomy is about
> > telescopes. -- Edsger Dijkstra