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.