----- Original Message -----
> From: "Cyril Hrubis" <chru...@suse.cz>
> To: "Jan Stancek" <jstan...@redhat.com>
> Cc: ltp-list@lists.sourceforge.net, jkast...@redhat.com
> Sent: Monday, 2 March, 2015 2:47:17 PM
> Subject: Re: [LTP] [PATCH 1/2] sched_setparam/9-1: fix hang on -rt kernel
>
> Hi!
> > > > static void test_process(void)
> > > > {
> > > > - /* to avoid blocking */
> > > > - alarm(2);
> > > > -
> > > > - while (1) {
> > > > - (*shmptr)++;
> > > > + struct sched_param param;
> > > > + time_t t1, t2;
> > > > +
> > > > + t1 = time(NULL);
> > > > + do {
> > > > + sched_getparam(getpid(), ¶m);
> > > > + (*shmptr) = param.sched_priority;
> > > > + /* if we can see that our priority has changed
> > > > + * that means we preempted parent, so we are done */
> > > > + if ((*shmptr) == mean_prio)
> > > > + break;
> > > > +
> > > > + t2 = time(NULL);
> > > > + /* immediately after parent forks us, we has same
> > > > + * priority and compete with parent for same CPU,
> > > > + * give parent chance to run and boost our priority */
> > > > sched_yield();
> > >
> > > Hmm, is this the case? Because the main thread should continue to run
> > > until blocked and without the sleep(1) in the main() there is nothing
> > > that could block the parent process between the fork and the priority
> > > boost. Or am I mistaken?
> >
> > I think you're right in scenario with single CPU.
> > In theory, is it possible that set_affinity() would be dummy, and one of
> > ncpu-1 children running with max FIFO priority would preempt parent
> > allowing test_process() to run before its priority is changed?
>
> Aren't the child proceesses forked with the same priority as the parent?
> In this case they shouldn't get executed for the same reason unless they
> are migrated other CPUs. But yes then it's a kind of unpredictable which
> is the reason we have the affinity call there.
Would you prefer I rewrite that comment? Or are you OK with the patch as it is?
Regards,
Jan
>
> > I'd prefer to keep sched_yield() in test_process() as it poses
> > no harm even in case parent can't be blocked/preempted.
>
> Ok.
>
> > > Shouldn't we rather initialize the shmptr to some known value (!=
> > > mean_prio) now?
> >
> > It's initialized to 0, after call to shmat.
>
> Missed that, you are right.
>
> --
> Cyril Hrubis
> chru...@suse.cz
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
