Re: [PATCH 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit

2013-08-20 Thread KOSAKI Motohiro
>> Hmm. I can do that, but wouldn't that make CONFIG_PREEMPT_VOLUNTARY >> mostly equivalent to CONFIG_PREEMPT_NONE? > > According the the Kconfig help, PREEMPT_VOLUNTARY is about the > *explicit* preemption points. And we do have a lot of them in > "might_sleep()". > > And personally, I think it ma

Re: [PATCH 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit

2013-08-14 Thread Michael S. Tsirkin
On Sat, Aug 10, 2013 at 08:42:58AM -0700, Linus Torvalds wrote: > On Fri, Aug 9, 2013 at 4:04 PM, Andi Kleen wrote: > > From: Andi Kleen > > > > Move the cond_resched() check for CONFIG_PREEMPT_VOLUNTARY into > > the low level copy_*_user code. This avoids some code bloat and > > makes check much

Re: [PATCH 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit

2013-08-10 Thread Jörn Engel
On Sat, 10 August 2013 20:23:09 +0200, Borislav Petkov wrote: > > Sounds like the debug aspect and the preemption point addition need > to be sorf-of split into two different functions/macros and each used > separately. > > Something like keep the current might_sleep and have debug_sleep or > sim

Re: [PATCH 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit

2013-08-10 Thread Borislav Petkov
On Sat, Aug 10, 2013 at 09:27:33AM -0700, Linus Torvalds wrote: > Now, the *debug* logic is entirely different, of course. Maybe the > problem is that we have mixed up the two so badly, and we have > "might_sleep()" that implies more of a debug issue than a preemption > issue, and then people add t

Re: [PATCH 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit

2013-08-10 Thread Linus Torvalds
On Sat, Aug 10, 2013 at 9:10 AM, Andi Kleen wrote: > > Hmm. I can do that, but wouldn't that make CONFIG_PREEMPT_VOLUNTARY > mostly equivalent to CONFIG_PREEMPT_NONE? According the the Kconfig help, PREEMPT_VOLUNTARY is about the *explicit* preemption points. And we do have a lot of them in "migh

Re: [PATCH 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit

2013-08-10 Thread Andi Kleen
> Most of this series looks fine, but I really think that we > could/should just take that extra step, and say "no, user accesses > don't imply that we need to check for scheduling". Hmm. I can do that, but wouldn't that make CONFIG_PREEMPT_VOLUNTARY mostly equivalent to CONFIG_PREEMPT_NONE? Need

Re: [PATCH 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit

2013-08-10 Thread Linus Torvalds
On Fri, Aug 9, 2013 at 4:04 PM, Andi Kleen wrote: > From: Andi Kleen > > Move the cond_resched() check for CONFIG_PREEMPT_VOLUNTARY into > the low level copy_*_user code. This avoids some code bloat and > makes check much more efficient by avoiding unnecessary function calls. May I suggest going

[PATCH 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit

2013-08-09 Thread Andi Kleen
From: Andi Kleen Move the cond_resched() check for CONFIG_PREEMPT_VOLUNTARY into the low level copy_*_user code. This avoids some code bloat and makes check much more efficient by avoiding unnecessary function calls. This is currently only for the non __ variants. For the sleep debug case the c