resend: KERNEL BUG: nice level should not affect SCHED_RR timeslice

resend: KERNEL BUG: nice level should not affect SCHED_RR timeslice

[Chris Friesen]

Apparently the timeslice of the SCHED_RR process varies with nice level 
the same way that it does for SCHED_OTHER.  So while niceness doesn't 
affect the priority of a SCHED_RR task, it does impact how much cpu it gets.

SUSv3 indicates, "Any processes or threads using SCHED_FIFO or SCHED_RR 
shall be unaffected by a call to setpriority()."

The code in set_user_nice() has a comment that leads me to believe the 
current behaviour is accidental (although I think the "not" in the last 
line isn't meant to be there):

/*
  * The RT priorities are set via sched_setscheduler(), but we still
  * allow the 'normal' nice value to be set - but as expected
  * it wont have any effect on scheduling until the task is
  * not SCHED_NORMAL/SCHED_BATCH:
  */

It appears that the desired behaviour is to allow setting the nice level 
of a realtime task, but to not have it affect anything until (and 
unless) it drops that realtime status.  Is this correct?

Chris

resend: KERNEL BUG: nice level should not affect SCHED_RR timeslice

[Chris Friesen]

I still haven't seen any replies, so I'm resending with a few more 
people directly in the TO list.

The timeslice of a SCHED_RR process currently varies with nice level the 
same way that it does for SCHED_OTHER.  I've included a small app below 
that demonstrates the issue.  So while niceness doesn't affect the 
priority of a SCHED_RR task, it does impact how much cpu it gets 
relative to other SCHED_RR tasks.

SUSv3 indicates, "Any processes or threads using SCHED_FIFO or SCHED_RR 
shall be unaffected by a call to setpriority()."

In addition, the code in set_user_nice() has a comment that leads me to 
believe the current behaviour is accidental (although I think the "not" 
in the last line of the comment isn't meant to be there):

/*
  * The RT priorities are set via sched_setscheduler(), but we still
  * allow the 'normal' nice value to be set - but as expected
  * it wont have any effect on scheduling until the task is
  * not SCHED_NORMAL/SCHED_BATCH:
  */

It appears that the desired behaviour is to allow setting the nice level 
of a realtime task, but to not have it affect anything until (and 
unless) it drops that realtime status.  This seems reasonable, but 
doesn't match current behaviour.

Chris


#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sched.h>
#include <errno.h>
#include <string.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <sys/resource.h>

#define THRESHOLD_USEC 2000

unsigned long long stamp()
{
	struct timeval tv;
	gettimeofday(&tv, 0);
	return (unsigned long long) tv.tv_usec + ((unsigned long long) 
tv.tv_sec)*1000000;
}

void chewcpu(int cpu)
{
	unsigned long long thresh_ticks = THRESHOLD_USEC;
	unsigned long long cur,last;
	
	last = stamp();
	while(1) {
		cur = stamp();
		unsigned long long delta = cur-last;
		if (delta > thresh_ticks) {
			printf("pid %d, out for %llu ms\n", getpid(), delta/1000);
			cur = stamp();
		}
		last = cur;
	}
		
}


int main()
{
	int cpu;
         cpu_set_t cpumask;
         CPU_ZERO(&cpumask);
         CPU_SET(0, &cpumask);

	int kidpid = fork();	
	
	struct sched_param p;
	p.sched_priority = 1;
	sched_setscheduler(0, SCHED_RR, &p);

	struct timespec ts;
	
	if (kidpid) {
		setpriority(PRIO_PROCESS, 0, 19);
		printf("pid %d, prio of %d\n", getpid(), getpriority(PRIO_PROCESS, 0));
		sched_rr_get_interval(0, &ts);
		printf("pid %d, interval of %d nsec\n", getpid(), ts.tv_nsec);
	} else {
		setpriority(PRIO_PROCESS, 0, -19);
		printf("pid %d, prio of %d\n", getpid(), getpriority(PRIO_PROCESS, 0));
		sched_rr_get_interval(0, &ts);
		printf("pid %d, interval of %d nsec\n", getpid(), ts.tv_nsec);
	}
		
	int rc = syscall(__NR_sched_setaffinity, 0, sizeof(cpumask), &cpumask);
         if (rc < 0)
                 printf("unable to set affinity: %m\n");
	

	sleep(1);
	
	chewcpu(cpu);
	return 0;
}

Re: resend: KERNEL BUG: nice level should not affect SCHED_RR timeslice

[Con Kolivas]

On Thursday 08 March 2007 10:19, Chris Friesen wrote:
> I still haven't seen any replies, so I'm resending with a few more
> people directly in the TO list.
>
> The timeslice of a SCHED_RR process currently varies with nice level the
> same way that it does for SCHED_OTHER.  I've included a small app below
> that demonstrates the issue.  So while niceness doesn't affect the
> priority of a SCHED_RR task, it does impact how much cpu it gets
> relative to other SCHED_RR tasks.
>
> SUSv3 indicates, "Any processes or threads using SCHED_FIFO or SCHED_RR
> shall be unaffected by a call to setpriority()."
>
> In addition, the code in set_user_nice() has a comment that leads me to
> believe the current behaviour is accidental (although I think the "not"
> in the last line of the comment isn't meant to be there):
>
> /*
>   * The RT priorities are set via sched_setscheduler(), but we still
>   * allow the 'normal' nice value to be set - but as expected
>   * it wont have any effect on scheduling until the task is
>   * not SCHED_NORMAL/SCHED_BATCH:
>   */
>
> It appears that the desired behaviour is to allow setting the nice level
> of a realtime task, but to not have it affect anything until (and
> unless) it drops that realtime status.  This seems reasonable, but
> doesn't match current behaviour.

Chris. 

Indeed we do change timeslice with nice on rt_tasks in mainline at the moment. 
Truth is most rt programming couldn't care less about timeslices, but your 
point about it deviating from the standard is valid. RSDL does not change 
timeslice with nice on SCHED_RR tasks so it's sort of getting addressed by 
proxy.

-- 
-ck

Re: resend: KERNEL BUG: nice level should not affect SCHED_RR timeslice

[Chris Friesen]

Con Kolivas wrote:

> Indeed we do change timeslice with nice on rt_tasks in mainline at the moment. 
> Truth is most rt programming couldn't care less about timeslices, but your 
> point about it deviating from the standard is valid. RSDL does not change 
> timeslice with nice on SCHED_RR tasks so it's sort of getting addressed by 
> proxy.

Unfortunately we have some vendor-supplied software that does care about 
timeslices.  It's a crazy thing with multiple SCHED_RR kernel threads 
that don't really self-manage very well.  They're spawned by a 
SCHED_OTHER task and inherit its nice level.

We modified the startup for the spawning task to run it at a lower nice 
level and were fairly surprised when the latency of message handling 
went way up.

Chris