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. Thank you for your activities in the scheduler area! Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
