Andrew Morton wrote:
> On Tue, 04 Jul 2006 15:32:19 +1000
> I expect raw_smp_processor_id() is used here as a a microoptimisation -
> avoid a might_sleep() which obviously will never trigger.
>
> But I think it'd be better to do just a single raw_smp_processor_id() for
> this entire function:
I agree, should have done that instead.
>> Racy? Start with an empty lru_in_use.
>>
>> Cpu A Cpu B
>> invalidate_bh_lrus()
>> mask = lru_in_use;
>> preempted
>> block I/O
>> bh_lru_install()
>> cpu_set(cpu, lru_in_use);
>> resume
>> cpus_clear(lru_in_use);
>> schedule_on_each_cpu_mask() - does not send IPI to cpu B
>
> Yup. I think we can fix that by doing a single cpu_clear() on each CPU
> just prior to that CPU clearing out its array, in invalidate_bh_lru().
I deliberately tried to avoid that to avoid the bitmask turning into a
bouncing cacheline.
> There's a possibility of course that new bh's will get installed somewhere,
> but higher-level code must ensure that those bh's do not belong to the
> device which we're trying to clean up.
Cheers,
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
