[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150123091353.GI2896@worktop.programming.kicks-ass.net>
Date: Fri, 23 Jan 2015 10:13:53 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [GIT PULL] sched: Fix missing preemption opportunity
I picked up the patch; will drop it if Ingo also does ;-)
On Thu, Jan 22, 2015 at 06:08:04PM +0100, Frederic Weisbecker wrote:
> +++ b/kernel/sched/core.c
> @@ -2877,6 +2877,21 @@ void __sched schedule_preempt_disabled(void)
> preempt_disable();
> }
>
> +static void preempt_schedule_common(void)
> +{
> + do {
> + __preempt_count_add(PREEMPT_ACTIVE);
> + __schedule();
> + __preempt_count_sub(PREEMPT_ACTIVE);
> +
> + /*
> + * Check again in case we missed a preemption opportunity
> + * between schedule and now.
> + */
> + barrier();
I do however wonder about this barrier() here; why do we think we need
it?
Is that because test_bit() it 'broken'? The bitops are typically atomic
ops and atomic reads should be through a volatile cast (x86
constant_test_bit doesn't seem to do this).
Should we go audit and fix that?
> + } while (need_resched());
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists