On Wed, Jun 04, 2014 at 07:57:07AM -0700, Andy Lutomirski wrote:
> On Wed, Jun 4, 2014 at 12:44 AM, Peter Zijlstra wrote:
> > On Tue, Jun 03, 2014 at 05:29:50PM -0700, Andy Lutomirski wrote:
> >> Currently, the only real guarantee provided by the polling bit is
> >> that, if you hold rq->lock and
On Wed, Jun 4, 2014 at 12:44 AM, Peter Zijlstra wrote:
> On Tue, Jun 03, 2014 at 05:29:50PM -0700, Andy Lutomirski wrote:
>> Currently, the only real guarantee provided by the polling bit is
>> that, if you hold rq->lock and the polling bit is set, then you can
>> set need_resched to force a resch
On Wed, Jun 4, 2014 at 12:53 AM, Peter Zijlstra wrote:
> On Tue, Jun 03, 2014 at 05:29:50PM -0700, Andy Lutomirski wrote:
>> @@ -229,6 +234,8 @@ static void cpu_idle_loop(void)
>>*/
>> preempt_set_need_resched();
>> tick_nohz_idle_exit();
>> +
On Tue, Jun 03, 2014 at 05:29:50PM -0700, Andy Lutomirski wrote:
> @@ -229,6 +234,8 @@ static void cpu_idle_loop(void)
>*/
> preempt_set_need_resched();
> tick_nohz_idle_exit();
> + __current_clr_polling();
> + smp_mb__after_clear_
On Tue, Jun 03, 2014 at 05:29:50PM -0700, Andy Lutomirski wrote:
> Currently, the only real guarantee provided by the polling bit is
> that, if you hold rq->lock and the polling bit is set, then you can
> set need_resched to force a reschedule.
>
> The only reason the lock is needed is that the id
5 matches
Mail list logo