[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ef03ceac-e7dc-f17a-8d4d-28adf90f6ded@redhat.com>
Date: Fri, 23 Oct 2020 11:33:09 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>,
Josh Don <joshdon@...gle.com>,
g@...ez.programming.kicks-ass.net
Cc: Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Eric Dumazet <edumazet@...gle.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
kvm@...r.kernel.org, Xi Wang <xii@...gle.com>
Subject: Re: [PATCH 1/3] sched: better handling for busy polling loops
On 23/10/20 09:19, Peter Zijlstra wrote:
>> + /*
>> + * preemption needs to be kept disabled between prepare_to_busy_poll()
>> + * and end_busy_poll().
>> + */
>> + BUG_ON(preemptible());
>> + if (allow_resched)
>> + preempt_enable();
>> + else
>> + preempt_enable_no_resched();
> NAK on @allow_resched
>
Since KVM is the one passing false, indeed I see no reason for the
argument; you can just use preempt_enable(). There is no impact for
example on the tracking of how much time was spent polling; that
ktime_get() for the end of the polling period is done before calling
end_busy_poll().
Paolo
Powered by blists - more mailing lists