On Jul 4, 2006, at 1:39 AM, Andrew Morton wrote:
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:
static void bh_lru_install(struct buffer_head *bh)
{
struct buffer_head *evictee = NULL;
struct bh_lru *lru;
+ int cpu;
check_irqs_on();
bh_lru_lock();
+ cpu = raw_smp_processor_id();
- lru = &__get_cpu_var(bh_lrus);
+ lru = per_cpu(bh_lrus, cpu);
The problem with this style is that it is an disoptimizatoin for
architectures who hold their per-cpu data offset in a register, put the
smp_processor_id in the per-cpu data (or similar) and per_cpu data
offsets in a global lookup.
Do we need a new macro? (what is that gcc macro function syntax?)
#ifdef PER_CPU_IS_SLOW
#define my_cpu_var(bh_lrus, cpu) \
({ BUG_ON(cpu != smp_processor_id()); &__get_cpu_var(bh_lrus); })
#else
#define my_cpu_var(bh_lrus, cpu) \
({ BUG_ON(cpu != smp_processor_id()); per_cpu(bh_lrus, cpu); })
#endif
(and yes, the BUG_ON would be for debug checking).
milton
-
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]
