Re: [RFC PATCH] sched: Remove set_task_state()

2017-01-03 Thread Mark Rutland
On Tue, Jan 03, 2017 at 10:06:58AM -0800, Davidlohr Bueso wrote: > On Tue, 03 Jan 2017, Mark Rutland wrote: > > >Does the below help? > > It does, yes. Performance is pretty much the same with either function > without sysreg. Great! > With arm no longer in the picture, I'll send up another pat

Re: [RFC PATCH] sched: Remove set_task_state()

2017-01-03 Thread Davidlohr Bueso
On Tue, 03 Jan 2017, Mark Rutland wrote: Does the below help? It does, yes. Performance is pretty much the same with either function without sysreg. With arm no longer in the picture, I'll send up another patchset with this change as well as Peter's cleanup remarks. Thanks, Davidlohr

Re: [RFC PATCH] sched: Remove set_task_state()

2017-01-03 Thread Mark Rutland
On Fri, Dec 30, 2016 at 10:17:53AM -0800, Davidlohr Bueso wrote: > Secondly for a higher overview, an unlink microbenchmark was used, > which pounds on a single file with open, close,unlink combos with > increasing thread counts (up to 4x ncpus). While the workload is > quite unrealistic, it does c

Re: [RFC PATCH] sched: Remove set_task_state()

2017-01-03 Thread Peter Zijlstra
On Fri, Dec 30, 2016 at 10:17:53AM -0800, Davidlohr Bueso wrote: > - set_task_state(current, TASK_RUNNING); > + set_current_state(TASK_RUNNING); Obviously good. > - set_task_state(tsk, TASK_UNINTERRUPTIBLE); > + set_current_state(TA

[RFC PATCH] sched: Remove set_task_state()

2016-12-30 Thread Davidlohr Bueso
This is a nasty interface and setting the state of a foreign task must not be done. While as of be628be0956 (bcache: Make gc wakeup sane, remove set_task_state()) everyone in the kernel calls set_task_state() with current, allowing the helper to be removed. However, as the comment indicates, it is