lkml.org 
[lkml]   [2015]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency selection
From
Date
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



\
 
 \ /
  Last update: 2015-12-18 20:41    [W:0.124 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site