> The page structure needs to be as small as possible. If its size
>happens to L1 align, then that is great, but otherwise it isn't worth the
>effort - the extra memory used to store the "padding" is much better used
>else where.
> Most accesses to the page struct are reads, this means it can live in
>the Shared state across mutilple L1 caches. The "slightly" common
>operation of incremented the ref-count/changing-flag-bits doesn't really
>come into play often enough to matter.
> Keeping the struct small can result in part of the page struct of
>interest in the L1 cache, along with part of the next one. As it isn't a
>heavily modified structure, with no spin locks, "false sharing" isn't a
>problem. Besides, the VM isn't threaded, so it isn't going to be playing
>ping-pong with the cache lines anyway.
I think the same thing applys to many places where we are using the slab
and we are right now requesting L1 cache alignment but the code is not
going to be SMP threaded for real (no spinlocks in the struct or/and
everything protected by the big kernel lock).
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/