lkml.org 
[lkml]   [1996]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: "Bug" in 2.0.x/2.1.x



On Tue, 17 Dec 1996, Andi Kleen wrote:
>
> In kernel/sched.c in Linux 2.0.x/2.1.x I see this:
>
> asmlinkage int sys_sched_rr_get_interval(pid_t pid, struct timespec *interval)
> {
> struct timespec t;
>
> t.tv_sec = 0;
> t.tv_nsec = 0; /* <-- Linus, please fill correct value in here */
> return -ENOSYS; /* and then delete this line. Thanks! */
> return copy_to_user(interval, &t, sizeof(struct timespec)) ? -EFAULT : 0;
> }
>
> See the problem? ;) I can't supply a patch because I don't know the length
> of a time slice in Linux (it is architecture dependent, isn't it?) and I don't
> have a POSIX.4 copy at hand.

It's defined by "DEF_PRIORITY" in ticks, currently

#define DEF_PRIORITY (20*HZ/100) /* 200 ms time slice */

so the correct value would probably be

t.tv_nsec = DEF_PRIORITY*1000000/HZ;

but that's just the system "default" value, and I suspect that the
function should return the per-process thing which is more like

t.tv_sec = current->priority * 1000000/HZ;

could you test it out and see if it works for you?

I don't want to change any of the RT stuff as I don't have any
test-programs that care about it, and as such I don't have any personal
interest..

Linus


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.255 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site