Skip to contentSkip to conversation

BFS 420: cleanup in tick handling

DISCUSSION Martin 2 participants 6 messages May 20, 2012 – May 23, 2012 4 messages not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Martin

author
#1 lore raw
Quoted 16 lines · Hillf Danton

The cpu on stack is not needed, so remove it.

kernel/sched/bfs.c +1 -4
@@ -2822,8 +2822,7 @@ void wake_up_idle_cpu(int cpu);
   */
  void scheduler_tick(void)
  {
-	int cpu __maybe_unused = smp_processor_id();
-	struct rq *rq = cpu_rq(cpu);
+	struct rq *rq = this_rq();
 
  	sched_clock_tick();
  	/* grq lock not grabbed, so only update rq clock */
--
--
Quoted 4 lines

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/

Hillf, I noticed you posting a few patches to BFS recently. Just wanted to make you aware that there is a certain erm communication issue between the kernel maintainers and the author of BFS. Since he is busy in real life you should contact him directly or cc him. See tail -1 Documentation/scheduler/sched-BFS.txt for email.

#2 lore raw

Hi Martin

Quoted 2 lines · Martin

Hillf, I noticed you posting a few patches to BFS recently. Just wanted to make you aware that there is a certain erm communication issue between the

Would you please feel free to elaborate on the issue, btw? I'd stop posting, yes?

Quoted 2 lines

kernel maintainers and the author of BFS. Since he is busy in real life you should contact him directly or cc him. See tail -1

Fine, lets disturb less.

Quoted 1 line

Documentation/scheduler/sched-BFS.txt for email.

A message that is not in the archive (sent off-list or not yet received): CANQmPXh+0LECyLJ-MrDBZf2ZwLv5BJk0+DCFgPzqSChrFV=2WA@mail.gmail.com

#4 lore raw
Quoted 3 lines · Chen

Actually the lowest deadline task selection algorithm now BFS used is O(n). I have already had an idea to enhance the lowest deadline task selection algorithm to O(1)

Would you please announce it on LKML?

A message that is not in the archive (sent off-list or not yet received): CANQmPXhYMbDG7Wiaiwbr3J+Fft3FnaS=RM2t=FSRN-hYDSbMzw@mail.gmail.com

#6 lore raw
Quoted 11 lines · Chen
Quoted 8 lines · 在 2012-5-22 下午9:50,"Hillf Danton" <[email protected]>写道:
Quoted 4 lines · Chen

Actually the lowest deadline task selection algorithm now BFS used is O(n).
I have already had an idea to enhance the lowest deadline task selection algorithm to O(1)

Would you please announce it on LKML?

Quoted 9 lines

First of all let me talk how to do it .We can use 40 list_head instead of the single list for time sharing scheduling policy.
Then for task selection we will select the task from these 40 list_head(actually not 40, just decide by next_sched_bit), then make a comparsion of these tasks(actually in the worse case we just need to do 40 times of comparsion) and pick the lowest task. If a task wake, it would be the first node of (queue + p->prio). If a task run out of its timeslice, it will become the last node of(queue + p->prio). This is a concept of BFS deadline presort algorithm and the time complexity is O(1)

Thank you for shedding light, I will study it soon.

A message that is not in the archive (sent off-list or not yet received): CANQmPXgqjSuo0jy-O04-qp64b4J-Lk64sv0wzmdG1yUtc9v-Sw@mail.gmail.com

#8 lore raw
Quoted 32 lines · Chen
Quoted 28 lines · 在 2012-5-22 下午10:04,"Hillf Danton" <[email protected]>写道:
Quoted 25 lines · Chen
Quoted 9 lines · 在 2012-5-22 下午9:50,"Hillf Danton" <[email protected]>写道:
Quoted 5 lines · Chen

Actually the lowest deadline task selection algorithm now BFS used is O(n).
I have already had an idea to enhance the lowest deadline task selection
algorithm to O(1)

Would you please announce it on LKML?

First of all let me talk how to do it .We can use 40 list_head instead of
the single list for time sharing scheduling policy.
Then for task selection we will select the task from these 40 list_head(actually not 40, just decide by next_sched_bit), then make a comparsion of these tasks(actually in the worse case we just need to do 40
times of comparsion) and pick the lowest task. If a task wake, it would be
the first node of (queue + p->prio). If a task run out of its timeslice, it
will become the last node of(queue + p->prio). This is a concept of BFS deadline presort algorithm and the time complexity is O(1)

Quoted 3 lines
Quoted 1 line

Thank you for shedding light, I will study it soon.

If you are free could you also help me to maintain my cpu scheduler, thanks. . :-)

No promise but try my best, ok?

#9 lore raw
In reply to a message not in the archive
Quoted 9 lines · Chen
Quoted 7 lines · 在 2012-5-22 下午9:50,"Hillf Danton" <[email protected]>写道:
Quoted 4 lines · Chen

Actually the lowest deadline task selection algorithm now BFS used is O(n).
I have already had an idea to enhance the lowest deadline task selection algorithm to O(1)

Quoted 8 lines
Quoted 1 line

Would you please announce it on LKML?

First of all let me talk how to do it .We can use 40 list_head instead of the single list for time sharing scheduling policy.
Then for task selection we will select the task from these 40 list_head(actually not 40, just decide by next_sched_bit), then make a comparsion of these tasks(actually in the worse case we just need to do 40 times of comparsion) and pick the lowest task.

If task is selected from one of the 40 lists by comparing deadline, then it is not fair scheduling, since no chance to select tasks on other lists.

Plus you have to comparing CPUs allowed with a given CPU, that said, O(1) is impossible, right?

Quoted 4 lines

If a task wake, it would be
the first node of (queue + p->prio). If a task run out of its timeslice, it will become the last node of(queue + p->prio). This is a concept of BFS deadline presort algorithm and the time complexity is O(1)

On other hand, I dont think O(1) is important, simply because if it is O(1) when dequeuing, it is not O(1) at all when enqueuing.

btw, you spend time maintaining RIFS, why?
-hd