sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH
Hello.
I beleive this patch against entry.S should be sufficient:
entry.S Sat Jul 6 21:06:14 2002 renamed from entry.S~ Sat Jul 6 21:01:16 2002 +1 -1
@@ -255,7 +255,7 @@ testb $_TIF_NEED_RESCHED, %cl jz work_notifysig work_resched: - call schedule + call schedule_userspace cli # make sure we don't miss an
interrupt
# setting need_resched or
sigpending
# between sampling and the iretBoth calls to schedule() at resume_kernel: and work_pending:
have clear kernel/user return path.
And users of __KERNEL_SYSCALLS__ and kernel_thread() should not have policy == SCHED_BATCH.
No?
Quoted 14 lines · On Sat, 6 Jul 2002 [email protected] wrote:
Hello.
I beleive this patch against
entry.Sshould be sufficient:entry.S Sat Jul 6 21:06:14 2002 renamed from entry.S~ Sat Jul 6 21:01:16 2002 +1
-1@@ -255,7 +255,7 @@ testb $_TIF_NEED_RESCHED, %cl jz work_notifysig work_resched: - call schedule + call schedule_userspace cli # make sure we don't miss aninterrupt
Quoted 6 lines
# setting need_resched or sigpending # between sampling and the iretBoth calls to
schedule()atresume_kernel: andwork_pending:
have clear kernel/user return path.
agreed, good catch. This greatly simplifies things.
Quoted 2 lines
And users of
__KERNEL_SYSCALLS__andkernel_thread()should not have policy ==SCHED_BATCH.
yep. And even if they do they should be aware of the consequences.
Ingo
Quoted 5 lines
Quoted 3 lines
And users of
__KERNEL_SYSCALLS__andkernel_thread()should not have policy ==SCHED_BATCH.yep. And even if they do they should be aware of the consequences.
well, there's one security consequence here - module loading (request_module()), which spawns a kernel thread must not run as SCHED_BATCH. I think the right solution for that path is to set the policy to SCHED_OTHER upon entry, and restore it to the previous one afterwards - this way the helper thread has SCHED_OTHER priority.
Ingo
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
And users of
__KERNEL_SYSCALLS__andkernel_thread()should not have policy ==SCHED_BATCH.well, there's one security consequence here - module loading (
request_module()), which spawns a kernel thread must not run asSCHED_BATCH. I think the right solution for that path is to set the policy toSCHED_OTHERupon entry, and restore it to the previous one afterwards - this way the helper thread hasSCHED_OTHERpriority.
i've solved this problem by making kernel_thread() spawned threads drop back to SCHED_NORMAL:
http://redhat.com/~mingo/O(1)-scheduler/sched-2.5.25-A7
I believe this is the secure way of doing it - independently of SCHED_BATCH - a RT task should not spawn a RT kernel thread 'unwillingly'.
Ingo
Hi!
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
And users of
__KERNEL_SYSCALLS__andkernel_thread()should not have policy ==SCHED_BATCH.well, there's one security consequence here - module loading (
request_module()), which spawns a kernel thread must not run asSCHED_BATCH. I think the right solution for that path is to set the policy toSCHED_OTHERupon entry, and restore it to the previous one afterwards - this way the helper thread hasSCHED_OTHERpriority.i've solved this problem by making
kernel_thread()spawned threads drop back toSCHED_NORMAL:
Does it mean that we now have working scheduler class that only schedules jobs when no other thread wants to run (as long as SCHED_BATCH task does not enter the kernel)?
Pavel
Signature · 2 lines
Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email?
Quoted 3 lines · Pavel Machek
Does it mean that we now have working scheduler class that only schedules jobs when no other thread wants to run (as long as
SCHED_BATCHtask does not enter the kernel)?
Yep.
Now, is the implementation OK?
Robert Love
Quoted 3 lines · Pavel Machek
Does it mean that we now have working scheduler class that only schedules jobs when no other thread wants to run (as long as
SCHED_BATCHtask does not enter the kernel)?
yes, that's exactly the point of SCHED_BATCH. Furthermore: it enables the correct timeslicing of such SCHED_BATCH tasks as well between each other - so it's not equivalent to 'infinitely low SCHED_NORMAL priority', but it's rather an additional hierarchy of scheduling classes. Plus it uses longer timeslices.
Ingo