Re: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency selection

From	Steve Muckle <steve.muckle@linaro.org>
Newsgroups	linux.kernel
Subject	Re: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency selection
Date	2015-12-18 20:20 +0100
Message-ID	<qH8Jk-1fV-9@gated-at.bofh.it> (permalink)
References	<qDGqd-4EB-3@gated-at.bofh.it> <qDGqe-4EB-23@gated-at.bofh.it> <qGbgd-4UV-5@gated-at.bofh.it> <qGvyi-13b-11@gated-at.bofh.it> <qGB10-4zr-11@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

Hi Leo,

On 12/16/2015 11:17 PM, Leo Yan wrote:
> Could you check if below corner case will introduce logic error?
> The task still will be removed from rq if timer tick is triggered
> between two time's set_current_state().
> 
> set_current_state(TASK_INTERRUPTIBLE);
>            `-------> timer_tick and
>                      schedule();
> do_something...
> set_current_state(TASK_RUNNING);
> 
> It will be safe for combination for set_current_state()/schedule()
> with waken_up_process():
> 
> Thread_A:                                       Thread_B:
> 
> set_current_state(TASK_INTERRUPTIBLE);
>              `-------> timer_tick and
>                        schedule();
> ....
>                                                 wake_up_process(Thread_A);
>                            <---------------------/
> schedule();
> 
> The first time's schedule() will remove task from rq which is caused
> by timer tick and call schedule(), and the second time schdule() will
> be equal yeild().

I was initially concerned about preemption while task state =
TASK_INTERRUPTIBLE as well, but a task with state TASK_INTERRUPTIBLE is
not dequeued if it is preempted. See core.c:__schedule():

        if (!preempt && prev->state) {
                if (unlikely(signal_pending_state(prev->state, prev))) {
                        prev->state = TASK_RUNNING;
                } else {
                        deactivate_task(rq, prev, DEQUEUE_SLEEP);
                        prev->on_rq = 0;

I knew this had to be the case, because this design pattern is used in
many other places in the kernel, so many things would be very broken if
this were a problem.

thanks,
Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

Re: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Leo Yan <leo.yan@linaro.org> - 2015-12-16 04:50 +0100
  Re: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Steve Muckle <steve.muckle@linaro.org> - 2015-12-17 02:30 +0100
    Re: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Leo Yan <leo.yan@linaro.org> - 2015-12-17 08:20 +0100
      Re: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Steve Muckle <steve.muckle@linaro.org> - 2015-12-18 20:20 +0100
        Re: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency  selection Leo Yan <leo.yan@linaro.org> - 2015-12-19 07:00 +0100

csiph-web