Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-18 Thread Takuya Yoshikawa
On Fri, 18 May 2012 09:26:05 +0200 Ingo Molnar wrote: > I'm not sure we had a usable spin_is_contended() back then, nor > was the !PREEMPT case in my mind really. The fact that both spin_needbreak() and spin_is_contended() can be used outside of sched is a bit confusing. For example, in mm/com

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-18 Thread Ingo Molnar
* Takuya Yoshikawa wrote: > Replaced Ingo's address with kernel.org one, > > On Thu, 03 May 2012 17:47:30 +0200 > Peter Zijlstra wrote: > > > On Thu, 2012-05-03 at 22:00 +0900, Takuya Yoshikawa wrote: > > > But as I could not see why spin_needbreak() was differently > > > implemented > > > de

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-10 Thread Takuya Yoshikawa
Replaced Ingo's address with kernel.org one, On Thu, 03 May 2012 17:47:30 +0200 Peter Zijlstra wrote: > On Thu, 2012-05-03 at 22:00 +0900, Takuya Yoshikawa wrote: > > But as I could not see why spin_needbreak() was differently > > implemented > > depending on CONFIG_PREEMPT, I wanted to understa

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Michael Wang
On 05/03/2012 09:00 PM, Takuya Yoshikawa wrote: > On Thu, 03 May 2012 14:29:10 +0200 > Peter Zijlstra wrote: > >> On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote: >>> Although the real use case is out of this RFC patch, we are now discussing >>> a case in which we may hold a spin_lock

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Peter Zijlstra
On Thu, 2012-05-03 at 22:00 +0900, Takuya Yoshikawa wrote: > But as I could not see why spin_needbreak() was differently > implemented > depending on CONFIG_PREEMPT, I wanted to understand the meaning. Its been that way since before voluntary preemption was introduced, so its possible Ingo simply

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Avi Kivity
On 05/03/2012 05:27 PM, Avi Kivity wrote: > On 05/03/2012 05:11 PM, Takuya Yoshikawa wrote: > > On Thu, 03 May 2012 15:47:26 +0300 > > Avi Kivity wrote: > > > > > On 05/03/2012 03:29 PM, Peter Zijlstra wrote: > > > > On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote: > > > > > Although the

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Avi Kivity
On 05/03/2012 05:11 PM, Takuya Yoshikawa wrote: > On Thu, 03 May 2012 15:47:26 +0300 > Avi Kivity wrote: > > > On 05/03/2012 03:29 PM, Peter Zijlstra wrote: > > > On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote: > > > > Although the real use case is out of this RFC patch, we are now > >

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Takuya Yoshikawa
On Thu, 03 May 2012 15:47:26 +0300 Avi Kivity wrote: > On 05/03/2012 03:29 PM, Peter Zijlstra wrote: > > On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote: > > > Although the real use case is out of this RFC patch, we are now discussing > > > a case in which we may hold a spin_lock for lo

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Takuya Yoshikawa
On Thu, 03 May 2012 14:29:10 +0200 Peter Zijlstra wrote: > On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote: > > Although the real use case is out of this RFC patch, we are now discussing > > a case in which we may hold a spin_lock for long time, ms order, depending > > on workload; and

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Avi Kivity
On 05/03/2012 03:29 PM, Peter Zijlstra wrote: > On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote: > > Although the real use case is out of this RFC patch, we are now discussing > > a case in which we may hold a spin_lock for long time, ms order, depending > > on workload; and in that case

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Peter Zijlstra
On Thu, 2012-05-03 at 21:22 +0900, Takuya Yoshikawa wrote: > Although the real use case is out of this RFC patch, we are now discussing > a case in which we may hold a spin_lock for long time, ms order, depending > on workload; and in that case, other threads -- VCPU threads -- should be > given h

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Takuya Yoshikawa
On Thu, 03 May 2012 10:35:27 +0200 Peter Zijlstra wrote: > On Thu, 2012-05-03 at 17:12 +0900, Takuya Yoshikawa wrote: > > > > Although we can do that using spin_is_contended() and cond_resched(), > > changing cond_resched_lock() to satisfy such a need is another option. > > > Yeah, not a pretty

Re: [RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Peter Zijlstra
On Thu, 2012-05-03 at 17:12 +0900, Takuya Yoshikawa wrote: > > Although we can do that using spin_is_contended() and cond_resched(), > changing cond_resched_lock() to satisfy such a need is another option. > Yeah, not a pretty patch. Changing all cond_resched_lock() sites just to change one and i

[RFC] sched: make callers check lock contention for cond_resched_lock()

2012-05-03 Thread Takuya Yoshikawa
This patch is for showing what I am thinking and only compile tested on linux-next, so an RFC. Although I might misread something, I am not sure whether every user of this API wanted to avoid contention check without CONFIG_PREEMPT. Any comments will be appreciated. Thanks, Takuya === F