[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150310010733.GA26844@brightrain.aerifal.cx>
Date: Mon, 9 Mar 2015 21:07:33 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: pthread object sizes for new archs
One issue that's arisen in merging the aarch64 port is that new glibc
ports keep making the pthread object sizes bigger and bigger, to the
point where aligning the size part of the ABI seems highly
detrimental. For example, the mutex sizes are:
glibc/musl 32-bit: 24 bytes
glibc/musl x86_64: 40 bytes
glibc aarch64: 48 bytes
Actually needed 32-bit: 20 bytes
Actually needed 64-bit: 32 bytes (28 + 4 padding for alignment)
I don't mind having extra space in the structure in case we want/need
to expand to meet new requirements or improve performance. But since
musl does not have or want arch-specific algorithm variants, there's
absolutely no use in one arch having more 'extra space' in its pthread
struct than another arch does; this space will never be used.
What I'd like to propose is that, for all new archs, we ignore the
glibc-provided size of the pthread types and stick with the baseline
32-bit sizes, enlarged only by the plausible number of fields that
could need to be pointers if the arch is 64-bit. For mutexes, I'd like
to stick to 32 bytes (33% increase going from 32-bit to 64-bit), but
40 (66% increase) wouldn't be horrible. The glibc aarch64 64-bit bloat
cost of 100% is ridiculous though.
If we go with 32 bytes, there's no slot available for use as a 64-bit
pointer without repurposing existing slots, while 32-bit archs can fit
an extra pointer. If we go with 40 bytes, the 64-bit archs have a lot
more space to expand (which they won't use).
One advantage of using a size of 40 is that we could just make the
x86_64 type sizes the universal 64-bit pthread type sizes and move
these types to an arch-independent file.
For what it's worth, if anyone is wondering why glibc keeps enlarging
these objects, it seems to be to work around bad core design that's
wasting large amounts of space. For example their mutex has separate
lock-word and owner-id fields, and I can't think of any explanation
for this except for accommodating legacy archs that lack atomic CAS
(which is needed for the more advanced types like robust mutexes
anyway). It also has a useless counter for the number of condition
variables currently using a mutex. As a result, despite being larger
than what musl needs, their baseline 32-bit mutex structure can't even
accommodate a doubly-linked list for robust mutexes, so robust mutex
unlock is O(n) in the number of robust locks held for removal from a
singly-linked list. So basically they seem to be pessimizing memory
usage on modern 64-bit archs, and pessimizing performance on modern
32-bit ones, to have baseline algorithms work on junk that's been
obsolete for decades and that store useless state.
I haven't done this much analysis of the other glibc types, but in any
case the same principle applies on musl's side: there's no sense in
making any of the pthread objects have more "extra space" than the
least amount of extra space they have on any existing arch. So I think
we should do the same thing and either go with the x86_64 sizes or
something smaller with "extra space" capacity comparable to the 32-bit
structs.
How does this affect "glibc ABI compatibility"? Very little. As long
as the sizes of the musl types are no larger than the sizes of the
glibc types on the same arch, compatibility with glibc binary code
(apps or libs) is not affected. All that is affected if the ABI of
third-party libraries that use pthread types as members of public
structs, and it only matters if you're calling such libraries using
the glibc-derived ABI from code compiled against musl and using the
affected structures. This is a very unusual usage case, not something
we've ever prioritized supporting (it's broken in several other ways
anyway, or at least it was historically), and IMO it's not worth
severely bloating new archs that people actually want to use.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
