Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[oleg]

Hello.

I beleive this patch against entry.S should be sufficient:

--- entry.S~    Sat Jul  6 21:01:16 2002
+++ entry.S     Sat Jul  6 21:06:14 2002
@@ -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 iret

Both 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?

Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[Ingo Molnar]

On Sat, 6 Jul 2002 oleg@tv-sign.ru wrote:

> Hello.
> 
> I beleive this patch against entry.S should be sufficient:
> 
> --- entry.S~    Sat Jul  6 21:01:16 2002
> +++ entry.S     Sat Jul  6 21:06:14 2002
> @@ -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 iret
> 
> Both calls to schedule() at resume_kernel: and work_pending:
> have clear kernel/user return path.

agreed, good catch. This greatly simplifies things.

> And users of __KERNEL_SYSCALLS__ and kernel_thread() should not
> have policy == SCHED_BATCH.

yep. And even if they do they should be aware of the consequences.

	Ingo

Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[Ingo Molnar]

> > And users of __KERNEL_SYSCALLS__ and kernel_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

Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[Ingo Molnar]

> > > And users of __KERNEL_SYSCALLS__ and kernel_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 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.

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

Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[Pavel Machek]

Hi!

> > > > And users of __KERNEL_SYSCALLS__ and kernel_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 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.
> 
> i've solved this problem by making kernel_thread() spawned threads drop
> back to SCHED_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
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[Robert Love]

On Sun, 2002-07-14 at 05:29, Pavel Machek wrote:

> 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)?

Yep.

Now, is the implementation OK?

	Robert Love

Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[Ingo Molnar]

On Sun, 14 Jul 2002, Pavel Machek wrote:

> 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)?

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

Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[Oleg Nesterov]

Hello.

> > > > And users of __KERNEL_SYSCALLS__ and kernel_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 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.
>
> i've solved this problem by making kernel_thread() spawned threads drop
> back to SCHED_NORMAL:

Note that request_module() also does waitpid(). So it's better to change
policy upon entry, as You suggested.

> 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'.

Yes, but this semantic change should be ported to all archs
independently of
low level microoptimizations, for consistency. Rename all definitions to
arch_kernel_thread() ?

Btw, how about this tiny bit of cleanup:

asmlinkage void schedule_userspace(void)
{
    /*
     * Only handle batch tasks that are runnable.
     */
    if (current->policy == SCHED_BATCH &&
        current->state == TASK_RUNNING) {
        runqueue_t *rq = this_rq_lock();
        deactivate_batch_task(current, rq);

        // we can keep irqs disabled:
        spin_unlock(&rq->lock);
    }

    schedule();
}

Oleg.

[patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

[Ingo Molnar]

the sched-2.5.24-D3 patch is my current scheduler tree against 2.5.24,
which also includes the latest version of SCHED_BATCH support:

	http://redhat.com/~mingo/O(1)-scheduler/sched-2.5.24-D3

the setbatch utility can be found at:

	http://redhat.com/~mingo/O(1)-scheduler/setbatch.c

Changes relative to the previous SCHED_BATCH patch:

 - fix signal delivery - call the 'kick batch processes' code on UP as
   well.

 - simplify and speed up the batch queue handling code: the expired/active
   queues are merged into a single queue. If a SCHED_BATCH process uses up
   all its timeslices then it is queued to the tail of the batch-queue -
   otherwise it's queued to the head of the batch-queue. This simplifies
   the load-balancer as well.

 - add 'default context-switch locking' if prepare_arch_schedule() is not 
   defined. The majority of architectures thus do not have to define the
   context-switch locking macros.

bug reports, success reports, comments, suggestions are welcome,

	Ingo