On 4/17/06, Om Narasimhan <om.turyx@xxxxxxxxx> wrote:
On 4/17/06, Jan Hudec <bulb@xxxxxx> wrote:
> On Sun, Apr 16, 2006 at 12:38:52 +0200, tyler@xxxxxxxx wrote:
> > On Sun, Apr 16, 2006 at 04:56:12PM +0800, Min-Hua Chen wrote:
> > > hi:
<snip>
> No bug, really. The comparison is INTEGERAL (there is no other in C, right)
> and preempt_count actually IS a COUNT, saying how many times preemption
> disable was requested. We are in atomic, if it was not requested, or it was
> requested by BKL (ie. kernel_locked() == 1 && preempt_count() == 1).
hm... I still have difficulty in understanding.
Does it mean that if the value of preempt_count (say X) is because of
X number of lock_kernel requests, it is preemptible?
preempt_count() not only represents no of the lock_kernel requests but also the softirq and hardirq counts and valid even with CONFIG_PREEMPT turned off. The LSB(0-7) bits indicate the preemption count(no. of lock_kernel requests). Depending on architecture bits (8-15) represent the softirq count and 16-27 the hardirq count.
bit 30 or bit 31(== PREMPT_ACTIVE) used as a special flag between preempt_schedule and schedule. If set doesn't mean that the kernel is not elgible to call schedule and hence the condition check.
Another question is, why the value of PREEMPT_ACTIVE is 0x10000000 in
i386? It seems to be different in different architectures
Different since it should not fall with the hardirq bits (which varies across architectures).
Thayumanavar S.
