32-bit powerpc and powerpc64 context, struct mtx NAME declarations vs. the reservation area for the likes of lwarx: should mtx_padalign be used instead?

[Mark Millard]

[This is just something I noted while trying to figure
out what might be leading to Data Storage Interrupt
problems for an iMac G3 (MPC750). Not that it is known
to contribute to anything that I've been looking at.]

Instructions like lwarx reserve a cache-line range
of RAM, for example:

A) MPC750: 32-bytes (Address&0x20 aligned)
B) 970MP: 128-bytes (Address&0x80 aligned)

For instances of:

struct mtx {
        struct lock_object      lock_object;    /* Common lock properties. */
        volatile uintptr_t      mtx_lock;       /* Owner and flags. */
};

such as:

. . .
struct mtx      moea_table_mutex;
struct mtx      moea_vsid_mutex;
static struct mtx tlbie_mtx;
. . .

the instances need not have distinct reservation areas for
mtx_lock use. (Some lock_object material will also likely
be in the reservation area.) The ". . ."s might also overlap
into the reservation area(s).

(I've ignored that the declaration order need not be the
in-memory order. But the general point stands.)

The:

. . .
struct mtx      moea64_slb_mutex;
. . .

and . . .

. . .
struct mtx pcicfg_mtx;
. . .

are similar. There could well be more. I did not try to
find them all.

There does appear to be:

struct mtx_padalign {
        struct lock_object      lock_object;    /* Common lock properties. */
        volatile uintptr_t      mtx_lock;       /* Owner and flags. */
} __aligned(CACHE_LINE_SIZE);

to help with avoiding such overlaps, but still leaving
(part of) lock_object as likely in the reservation area
with the mtx_lock field.

(CACHE_LINE_SIZE seems to be 128 for 32-bit powerpc and
powerpc64, if I remember right.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)