Sorry, delay reply.
> Yup. What BITMAP_SIZE does is find the smallest array of longs that
> would fit MAX_PRIO bits. That size is 5 on 32-bit machines, since
> (5*32=160) > (MAX_PRIO=140) > (4*32=128).
>
> And that b[0]..b[4] is exactly what sched_find_first_bit() checks. So
> b[0] is the first 32-bits, corresponding to priority 0..31, etc.
I see. But according to sched_find_first_bit(),
static inline int sched_find_first_bit(const unsigned long *b)
{
if (unlikely(b[0]))
return __ffs(b[0]);
if (unlikely(b[1]))
return __ffs(b[1]) + 32;
if (unlikely(b[2]))
return __ffs(b[2]) + 64;
if (b[3])
return __ffs(b[3]) + 96;
return __ffs(b[4]) + 128;
}
It seems that b[0] has the most highest priority bit since it comes
first. The priority 0 you said refers to the most highest?
But I've understood the task which is not real-time task has priority 0
at the "rt_priority" member.
Is this priority different from what rt_priority refers to?
Regards,
Shinpei Kato
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
