* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > -static DEFINE_PER_CPU(struct rq, runqueues);
> > +static DEFINE_PER_CPU(struct rq, runqueues) ____cacheline_aligned_in_smp;
>
> Remember that this can consume up to (linesize-4 * NR_CPUS) bytes,
> which is rather a lot.
yes - but one (special) issue here is that there are other 'hot' but
truly per-CPU structures nearby:
ffffffff8067e800 D per_cpu__current_kprobe
ffffffff8067e820 D per_cpu__kprobe_ctlblk
ffffffff8067e960 D per_cpu__mmu_gathers
ffffffff8067f960 d per_cpu__runqueues
ffffffff80680c60 d per_cpu__cpu_domains
ffffffff80680df0 d per_cpu__sched_group_cpus
cpu_domains is being dirtied too (sd->nr_balance_failed,
sd->last_balanc, etc.) and mmu_gathers too. So while both mmu_gathers
and cpu_domains are mostly purely per-CPU, runqueue fields can bounce
around alot and drag those nearby fields with them (and then get dragged
back due to those nearby fields being used per-CPU again.)
the runqueue is really supposed to be cacheline-isolated at _both_ ends
- at its beginning and at its end as well.
> And that putting a gap in the per-cpu memory like this will reduce its
> overall cache-friendliness.
yes - although the per-cpu runqueue overhead is nearly 5K anyway.
> Remember also that the linesize on VSMP is 4k.
that sucks ...
maybe, to mitigate some of the costs, do a special PER_CPU_CACHE_ALIGNED
area that collects per-cpu fields that also have significant cross-CPU
use and need cacheline isolation? Such cacheline-aligned variables, if
collected separately, would pack up more tightly and would cause only
half of the wasted space.
Ingo
-
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/
