All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirill Tkhai <tkhai@yandex.ru>
To: Andreas Mohr <andi@lisas.de>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@redhat.com
Subject: Re: [PATCH] sched: Transform resched_task() into resched_curr()
Date: Sun, 29 Jun 2014 11:57:49 +0400	[thread overview]
Message-ID: <53AFC6FD.5070508@yandex.ru> (raw)
In-Reply-To: <20140629072059.GA18636@rhlx01.hs-esslingen.de>

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

  reply	other threads:[~2014-06-29  8:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-29  7:20 [PATCH] sched: Transform resched_task() into resched_curr() Andreas Mohr
2014-06-29  7:57 ` Kirill Tkhai [this message]
2014-06-29  8:36   ` Andreas Mohr
2014-06-29  8:59     ` Kirill Tkhai
2014-06-29 10:54       ` Andreas Mohr
  -- strict thread matches above, loose matches on Subject: below --
2014-06-28 20:03 Kirill Tkhai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53AFC6FD.5070508@yandex.ru \
    --to=tkhai@yandex.ru \
    --cc=andi@lisas.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.