Re: [PATCH RT 2/2] softirq: split timer softirqs out of ksoftirqd

2016-06-06 Thread Brian Silverman
the HRTIMER softirq to wake it up. That was with ksoftirqd running as SCHED_OTHER, which is what it defaulted to. The priority inversion between the userspace processes is gone after making ktimersoftd the same priority as the highest-priority application. Tested-by: Brian Silverman <br...@peloton-tech.com>

Re: [PATCH RT 2/2] softirq: split timer softirqs out of ksoftirqd

2016-06-06 Thread Brian Silverman
the HRTIMER softirq to wake it up. That was with ksoftirqd running as SCHED_OTHER, which is what it defaulted to. The priority inversion between the userspace processes is gone after making ktimersoftd the same priority as the highest-priority application. Tested-by: Brian Silverman

Re: [PATCH] Force processes to non-realtime before mm_exit

2016-06-03 Thread Brian Silverman
Sebastian had some questions about this patch when I first sent it to rt-users. On Wed, May 25, 2016 at 12:54 PM, Sebastian Andrzej Siewior <bige...@linutronix.de> wrote: > On 05/25/2016 08:00 PM, Brian Silverman wrote: >>> Why can't the application drop the RT priority before

Re: [PATCH] Force processes to non-realtime before mm_exit

2016-06-03 Thread Brian Silverman
Sebastian had some questions about this patch when I first sent it to rt-users. On Wed, May 25, 2016 at 12:54 PM, Sebastian Andrzej Siewior wrote: > On 05/25/2016 08:00 PM, Brian Silverman wrote: >>> Why can't the application drop the RT priority before its exit? Wouldn't >>>

[PATCH] Force processes to non-realtime before mm_exit

2016-06-03 Thread Brian Silverman
Without this, a realtime process which has called mlockall exiting causes large latencies for other realtime processes at the same or lower priorities. This seems like a fairly common use case too, because realtime processes generally want their memory locked into RAM. Signed-off-by: Brian

[PATCH] Force processes to non-realtime before mm_exit

2016-06-03 Thread Brian Silverman
Without this, a realtime process which has called mlockall exiting causes large latencies for other realtime processes at the same or lower priorities. This seems like a fairly common use case too, because realtime processes generally want their memory locked into RAM. Signed-off-by: Brian

[tip:sched/core] sched: Fix RLIMIT_RTTIME when PI-boosting to RT

2015-03-23 Thread tip-bot for Brian Silverman
Commit-ID: 746db9443ea57fd9c059f62c4bfbf41cf224fe13 Gitweb: http://git.kernel.org/tip/746db9443ea57fd9c059f62c4bfbf41cf224fe13 Author: Brian Silverman AuthorDate: Wed, 18 Feb 2015 16:23:56 -0800 Committer: Ingo Molnar CommitDate: Mon, 23 Mar 2015 10:47:55 +0100 sched: Fix

[tip:sched/core] sched: Fix RLIMIT_RTTIME when PI-boosting to RT

2015-03-23 Thread tip-bot for Brian Silverman
Commit-ID: 746db9443ea57fd9c059f62c4bfbf41cf224fe13 Gitweb: http://git.kernel.org/tip/746db9443ea57fd9c059f62c4bfbf41cf224fe13 Author: Brian Silverman br...@peloton-tech.com AuthorDate: Wed, 18 Feb 2015 16:23:56 -0800 Committer: Ingo Molnar mi...@kernel.org CommitDate: Mon, 23 Mar 2015

Re: CONFIG_PREEMPT_RT local_softirq_pending warning when ISR blocks

2015-03-09 Thread Brian Silverman
On Mon, Mar 9, 2015 at 12:08 PM, Sebastian Andrzej Siewior wrote: > * Brian Silverman | 2015-03-05 00:16:20 [-0500]: > >>Beforehand, 000 is spending most of its time in interrupts, but bash >>is doing something related to memory management on it in between. >>

Re: [PATCH] sched: fix RLIMIT_RTTIME when PI-boosting to RT

2015-03-09 Thread Brian Silverman
On Mon, Mar 9, 2015 at 1:34 PM, Sebastian Andrzej Siewior wrote: > From what I can tell not beeing a sched guy is that the patch looks > reasonable since the timeout gets only set to zero on enqueue_task_rt(). > Is there something special you do to trigger this? I posted some test code with two

Re: CONFIG_PREEMPT_RT local_softirq_pending warning when ISR blocks

2015-03-09 Thread Brian Silverman
On Mon, Mar 9, 2015 at 12:08 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: * Brian Silverman | 2015-03-05 00:16:20 [-0500]: Beforehand, 000 is spending most of its time in interrupts, but bash is doing something related to memory management on it in between. bash-14721

Re: [PATCH] sched: fix RLIMIT_RTTIME when PI-boosting to RT

2015-03-09 Thread Brian Silverman
On Mon, Mar 9, 2015 at 1:34 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: From what I can tell not beeing a sched guy is that the patch looks reasonable since the timeout gets only set to zero on enqueue_task_rt(). Is there something special you do to trigger this? I posted some

CONFIG_PREEMPT_RT local_softirq_pending warning when ISR blocks

2015-03-04 Thread Brian Silverman
=swapper/1 next_pid=0 next_prio=120 ... -0 [001] d...1.. 6854.629319: softirq_check_pending_idle <-tick_nohz_idle_enter My tracing_off() call is in softirq_check_pending_idle, so that's it. Thanks, Brian Silverman -- To unsubscribe from this list: send the line "unsubscribe

CONFIG_PREEMPT_RT local_softirq_pending warning when ISR blocks

2015-03-04 Thread Brian Silverman
is in softirq_check_pending_idle, so that's it. Thanks, Brian Silverman -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] sched: fix RLIMIT_RTTIME when PI-boosting to RT

2015-02-18 Thread Brian Silverman
M, wrote: > From: Brian Silverman > > When non-realtime tasks get priority-inheritance boosted to a realtime > scheduling class, RLIMIT_RTTIME starts to apply to them. However, the > counter used for checking this (the same one used for SCHED_RR > timeslices) was not getting reset. T

Re: [PATCH] sched: fix RLIMIT_RTTIME when PI-boosting to RT

2015-02-18 Thread Brian Silverman
); assert(pthread_create(rt, NULL, realtime, NULL) == 0); assert(pthread_join(nrt, NULL) == 0); assert(pthread_join(rt, NULL) == 0); return 0; } On Wed, Feb 18, 2015 at 7:23 PM, br...@peloton-tech.com wrote: From: Brian Silverman br...@peloton-tech.com When non-realtime tasks get priority

[tip:locking/urgent] futex: Fix a race condition between REQUEUE_PI and task death

2014-10-26 Thread tip-bot for Brian Silverman
Commit-ID: 30a6b8031fe14031ab27c1fa3483cb9780e7f63c Gitweb: http://git.kernel.org/tip/30a6b8031fe14031ab27c1fa3483cb9780e7f63c Author: Brian Silverman AuthorDate: Sat, 25 Oct 2014 20:20:37 -0400 Committer: Thomas Gleixner CommitDate: Sun, 26 Oct 2014 16:16:18 +0100 futex: Fix a race

[tip:locking/urgent] futex: Fix a race condition between REQUEUE_PI and task death

2014-10-26 Thread tip-bot for Brian Silverman
Commit-ID: 30a6b8031fe14031ab27c1fa3483cb9780e7f63c Gitweb: http://git.kernel.org/tip/30a6b8031fe14031ab27c1fa3483cb9780e7f63c Author: Brian Silverman bsilver16...@gmail.com AuthorDate: Sat, 25 Oct 2014 20:20:37 -0400 Committer: Thomas Gleixner t...@linutronix.de CommitDate: Sun, 26 Oct

[PATCH v2] futex: fix a race condition between REQUEUE_PI and task death

2014-10-25 Thread Brian Silverman
are usually a mess, to the point of crashing tools used to examine them. Signed-off-by: Brian Silverman --- kernel/futex.c | 44 +++- 1 file changed, 27 insertions(+), 17 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index 815d7af..c2

Re: [PATCH] futex: fix a race condition between REQUEUE_PI and task death

2014-10-25 Thread Brian Silverman
On Sat, 25 Oct 2014, Thomas Gleixner wrote: > > pi_state_free and exit_pi_state_list both clean up futex_pi_state's. > > exit_pi_state_list takes the hb lock first, and most callers of > > pi_state_free do too. requeue_pi didn't, which causes lots of problems. > > "causes lots of problems" is not

Re: [PATCH] futex: fix a race condition between REQUEUE_PI and task death

2014-10-25 Thread Brian Silverman
On Sat, 25 Oct 2014, Thomas Gleixner wrote: pi_state_free and exit_pi_state_list both clean up futex_pi_state's. exit_pi_state_list takes the hb lock first, and most callers of pi_state_free do too. requeue_pi didn't, which causes lots of problems. causes lots of problems is not really a

[PATCH v2] futex: fix a race condition between REQUEUE_PI and task death

2014-10-25 Thread Brian Silverman
a mess, to the point of crashing tools used to examine them. Signed-off-by: Brian Silverman bsilver16...@gmail.com --- kernel/futex.c | 44 +++- 1 file changed, 27 insertions(+), 17 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index 815d7af

Re: [PATCH] futex: fix a race condition between REQUEUE_PI and task death

2014-10-23 Thread Brian Silverman
PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0)); int i; for (i = 0; i < NUMBER_TESTERS; ++i) { if (fork() == 0) { while (1) { RunTest(_memory[i]); } } } } On Thu, O

[PATCH] futex: fix a race condition between REQUEUE_PI and task death

2014-10-23 Thread Brian Silverman
tools used to examine them. Signed-off-by: Brian Silverman --- I am not subscribed to the list so please CC me on any responses. kernel/futex.c | 32 +--- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index 815d7af

[PATCH] futex: fix a race condition between REQUEUE_PI and task death

2014-10-23 Thread Brian Silverman
tools used to examine them. Signed-off-by: Brian Silverman bsilver16...@gmail.com --- I am not subscribed to the list so please CC me on any responses. kernel/futex.c | 32 +--- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/kernel/futex.c b/kernel

Re: [PATCH] futex: fix a race condition between REQUEUE_PI and task death

2014-10-23 Thread Brian Silverman
; for (i = 0; i NUMBER_TESTERS; ++i) { if (fork() == 0) { while (1) { RunTest(shared_memory[i]); } } } } On Thu, Oct 23, 2014 at 3:22 PM, Brian Silverman bsilver16...@gmail.com wrote: pi_state_free and exit_pi_state_list both clean up futex_pi_state's