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 operating on task scope alone, > except for interesting lockdep_assert_held() outer-env validation-only parts) > to one which has a *broader* scope (namely, wholly rq-parameterized), > thus now drawing the rq dependency into the equation: > this patch introduces access to rq->curr specifics *within > function implementation* (as the first measure within a function, > which in itself might be considered a smell), > and it needlessly widens the scope of concerns of this handler > by now enabling full access to any rq struct members there - > we'll then end up with the next guy introducing > some strange dependency on other rq parts within this handler > which that guy would not have been tempted to do in the first place > if it had remained strictly task-based...... > > I'd wager that the size benefit possibly dominantly stems from > getting rid of rq->curr indirection lookup at the many user call sites. > Thus it might be a good idea > to instead create a non-inlined resched_curr() wrapper > which merely forwards to resched_task(), > to have the currently strictly task-focussed (pun intended ;) approach > of resched_task() properly preserved. > > Generally spoken, this incident and the "interesting" status quo > of very often doing an open-coded rq->curr lookup when calling resched_task() > could prompt a rethinking of relationship of task vs. rq, > since by clearing up (and focussing on) design intentions, > one could "automatically" end up > with more elegant and thus better function implementations.
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 have any problems because of this. We only can reschedule the current task, and the patch underlines that fact. > > > Thank you for your activities in the scheduler area! > > Andreas Mohr > Thanks, Kirill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
