On Sun, Jun 29, 2014 at 12:59:41PM +0400, Kirill Tkhai wrote:
> On 29.06.2014 12:36, Andreas Mohr wrote:
> > I just noticed that there is a part touching rq->idle,
> > and ISTR that idle task handling is "special"
> > (after all that's the power management side of things).
> > Specifically, rq->cur
On 29.06.2014 12:36, Andreas Mohr wrote:
> Hi,
>
> On Sun, Jun 29, 2014 at 11:57:49AM +0400, Kirill Tkhai wrote:
>> resched_curr(rq) means "to reschedule current task of the rq". It does
>> not reschedule rq itself.
>>
>> We already have resched_cpu(), which has cpu agrument, and it's not
>> a tas
Hi,
On Sun, Jun 29, 2014 at 11:57:49AM +0400, Kirill Tkhai wrote:
> resched_curr(rq) means "to reschedule current task of the rq". It does
> not reschedule rq itself.
>
> We already have resched_cpu(), which has cpu agrument, and it's not
> a task. I think this is just a similar case and we won't
Hi, Andreas,
On 29.06.2014 11:20, Andreas Mohr wrote:
> Hi,
>
> I cannot speak too much about scheduler specifics, but from a structural POV
> I'm unsure about such a change (into this direction).
>
> We seem to be going from a nicely fine-grained function
> (task-struct-specific, and thus opera
Hi,
I cannot speak too much about scheduler specifics, but from a structural POV
I'm unsure about such a change (into this direction).
We seem to be going from a nicely fine-grained function
(task-struct-specific, and thus operating on task scope alone,
except for interesting lockdep_assert_held(
We always use resched_task() with rq->curr argument.
It's not possible to reschedule any task but rq's current.
The patch introduces resched_curr(struct rq *) to
replace all of the repeating patterns. The main aim
is cleanup, but there is a little size profit too:
(before)
$ size kernel/sched/bui
6 matches
Mail list logo
