Date: Tue, 23 Apr 2019 16:02:32 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com> Subject: 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? Message-ID: <675FD8EE-384D-4D31-9B27-036ECEE717B0@yahoo.com>
next in thread | raw e-mail | index | archive | help
[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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?675FD8EE-384D-4D31-9B27-036ECEE717B0>