From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 5/5] open_posix: condvar/schedule: mask SIGALRM in SCHED_OTHER threads
Date: Tue, 23 Feb 2016 11:00:27 +0100 [thread overview]
Message-ID: <20160223100027.GA1526@rei.lan> (raw)
In-Reply-To: <1602365858.25927894.1456212883119.JavaMail.zimbra@redhat.com>
Hi!
> > I guess that the test could be changed to:
> >
> > * Lock one high priority thread on cond variable
> > * Run one low priority thread that does sleep(1) then
> > calls pthread_cond_signal()
> > * Run one bussy loop low priority thread
> >
> > That way we would avoid the signal handlers entirely. What do you think?
>
> Would it be enough to:
> - call set_affinity_single() to have it all run on single CPU
> - spawn high prio thread and wait for it to block on condition
> - spawn low prio thread and singal condition, then busy loop for couple seconds
>
> And we can be also sure that high prio thread preempted low prio thread
> regardless of number of CPUs on system.
>
Good idea. I would use affinity on the bussy thread and the high
priority thread and let the low priority thread that calls the signal
function without any affinity.
That way the condition signaling would be trully asynchronous on SMP
system (and the test will work on single CPU as well since SCHED_RR will
wake up the signaling thread sooner or later since it has the same
priority as the bussy loop one).
> Also, any objections if we split the series? If I fix 1/5 and skip 5/5
> for now, those 4 could go in now and then next series would be series
> that removes signal handlers from all.
Sure. I've acked these patches allready :)
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2016-02-23 10:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 10:03 [LTP] [PATCH 1/5] open_posix: add SAFE_PFUNC macro Jan Stancek
2016-02-19 10:03 ` [LTP] [PATCH 2/5] open_posix: condvar/schedule: use SAFE_PFUNC Jan Stancek
2016-02-22 13:42 ` Cyril Hrubis
2016-02-19 10:03 ` [LTP] [PATCH 3/5] open_posix: condvar/schedule: remove useless waiting Jan Stancek
2016-02-22 14:57 ` Cyril Hrubis
2016-02-19 10:03 ` [LTP] [PATCH 4/5] open_posix: condvar/schedule: remove duplicit setsched calls Jan Stancek
2016-02-22 15:38 ` Cyril Hrubis
2016-02-19 10:03 ` [LTP] [PATCH 5/5] open_posix: condvar/schedule: mask SIGALRM in SCHED_OTHER threads Jan Stancek
2016-02-22 16:09 ` Cyril Hrubis
2016-02-23 7:34 ` Jan Stancek
2016-02-23 10:00 ` Cyril Hrubis [this message]
2016-02-23 12:44 ` Jan Stancek
2016-02-22 13:35 ` [LTP] [PATCH 1/5] open_posix: add SAFE_PFUNC macro Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160223100027.GA1526@rei.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox