Re: sched_find_first_bit()

[Shinpei Kato <shinny@j02.itscom.net>]

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/