--
> +
> +struct cpu_priority {
> + raw_spinlock_t lock;
> + cpumask_t pri_to_cpu[CPUPRI_NR_PRIORITIES];
> + long pri_active[CPUPRI_NR_PRIORITIES/BITS_PER_LONG];
> + int cpu_to_pri[NR_CPUS];
> +};
> +
> +static __cacheline_aligned_in_smp struct cpu_priority cpu_priority;
> +
[...]
> +int cpupri_find(int def_cpu, struct task_struct *p)
> +{
> + int idx = 0;
> + struct cpu_priority *cp = &cpu_priority;
> + int this_cpu = smp_processor_id();
> + int cpu = def_cpu;
> + int task_pri = convert_prio(p->prio);
> +
> + for_each_cpupri_active(cp->pri_active, idx) {
[...]
> +void cpupri_set(int cpu, int newpri)
> +{
> + struct cpu_priority *cp = &cpu_priority;
> + int *currpri = &cp->cpu_to_pri[cpu];
> + int oldpri = *currpri;
> + unsigned long flags;
> +
> + newpri = convert_prio(newpri);
> +
> + if (newpri == oldpri)
> + return;
> +
> + spin_lock_irqsave(&cp->lock, flags);
The cpu_priority and the cp->lock will be aboslutely horrible for
cacheline bouncing. Ironically, this will kill performance for the very
machines this code is to help with. The larger the number of CPUs you
have the more cacheline bouncing this code will create.
I still don't see the benefit from the cpupri code.
-- Steve
-
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]
