This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Cc: nd at arm dot com
- Date: Mon, 30 Apr 2018 11:27:06 -0400
- Subject: Re: aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT
- Autocrypt: addr=carlos at redhat dot com; prefer-encrypt=mutual; keydata= xsFNBFef5BoBEACvJ15QMMZh4stKHbz0rs78XsOdxuug37dumTx6ngrDCwZ61k7nHQ+uxLuo QvLSc6YJGBEfiNFbs1hvhRFNR7xJbzRYmin7kJZZ/06fH2cgTkQhN0mRBP8KsKKT+7SvvBL7 85ZfAhArWf5m5Tl0CktZ8yoG8g9dM4SgdvdSdzZUaWBVHc6TjdAb9YEQ1/jpyfHsQp+PWLuQ ZI8nZUm+I3IBDLkbbuJVQklKzpT1b8yxVSsHCyIPFRqDDUjPL5G4WnUVy529OzfrciBvHdxG sYYDV8FX7fv6V/S3eL6qmZbObivIbLD2NbeDqw6vNpr+aehEwgwNbMVuVfH1PVHJV8Qkgxg4 PqPgQC7GbIhxxYroGbLJCQ41j25M+oqCO/XW/FUu/9x0vY5w0RsZFhlmSP5lBDcaiy3SUgp3 MSTePGuxpPlLVMePxKvabSS7EErLKlrAEmDgnUYYdPqGCefA+5N9Rn2JPfP7SoQEp2pHhEyM 6Xg9x7TJ+JNuDowQCgwussmeDt2ZUeMl3s1f6/XePfTd3l8c8Yn5Fc8reRa28dFANU6oXiZf 7/h3iQXPg81BsLMJK3aA/nyajRrNxL8dHIx7BjKX0/gxpOozlUHZHl73KhAvrBRaqLrr2tIP LkKrf3d7wdz4llg4NAGIU4ERdTTne1QAwS6x2tNa9GO9tXGPawARAQABzSlDYXJsb3MgTydE b25lbGwgPGNhcmxvc0BzeXN0ZW1oYWx0ZWQub3JnPsLBgQQTAQIAKwIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4ACGQEFAle9yycFCQPB+4cACgkQFnkrTqJTQPjGbA//VKfjZs1Bv0fW wWWwpIK5gFfU+TyKJ1jp3hjZPwM8Z+/tJdoio1CEWeMpg603FueiTYj5iYHi6ueWWCpF6Lro 1/vtLaeJJF29PByu/DsIc5MKXpwA4btoNGu1LkUsLP5ksNOzG2bWcorP4us7Lkho+6DuZTY1 SsM5Zh236TtAqaWbBczHUmIECZM616n/3Hjp0UN9WnlAw0izTkEcXh3MQd5IVh/bmgW6f60s TIc1D9GSHcJDZq0XYDllZv+hHSfmJry7zzeoA9CCVPqcMJ3aZcPYd6d9HHDyeTPxQ6ra0Nu7 i1glvNyDu1ZyZq//AOlm2Rhx5y2msblPLQuW6HcBDeOhJjXPZ5b8Rjw3TM9ZM/lSD63GMTuW yA9bBl+qpXqcEA87H5s1qg+JTrSXx76f0t4bNuL58Nj3ABxiPC8/yzlPJ8G+hIVp787HynEO /2fzWOmdUF8emAJ6GeVaGpwwV/U0AJY1n2zPmSMQdEgAP/m58psAnJ/p9aklDmG9EjH2solE uXBKIDnnPQi8sUxbt+ewtKB+XZkn+GgmXymLQjbiuRMnSoY1jdN9xOQSys7dRveZIQvLjOYJ GoiWyPM/yK2XiNoX90n8JB6snI7fIPAOXat9j42WrGn9qwlk6w3XU0ffWG8PMxfQwTIBPv2R PsUfK0GoDPCJL0uWrfXE1OfOwU0EV5/kGgEQAKvTJke+QSjATmz11ALKle/SSEpUwL5QOpt3 xomEATcYAamww0HADfGTKdUR+aWgOK3vqu6Sicr1zbuZjHCs2GaIgRoqh1HKVgCmaJYjizvi dHluqrox6qqc9PG0bWb0f5xGQw+X2z+bEinzv4qaep1G1OuYgvG49OpHTgZMiJq9ncHCxkD2 VEJKgMywGJ4Agdl+NWVn0T7w6J+/5QmBIE8hh4NzpYfrxzWCJ9iZ3skG4zBGB4YEacc3+oeE oybc10h6tqhQNrtIiSRJH+SUJvOiNH8oMXPLAjfFVy3d4BOgyxJhE0UhmQIQHMJxCBw81fQD 10d0dcru0rAIEldEpt2UXqOr0rOALDievMF/2BKQiOA7PbMC3/dwuNHDlClQzdjil8O7UsIg f3IMFaIbQoUEvjlgf5cm9a94gWABcfI1xadAq9vcIB5v+9fM71xDgdELnZThTd8LByrG99Ex VMcG2PZYXJllVDQDZqYA1PjD9e0yHq5whJi3BrZgwDaL5vYZEb1EMyH+BQLO3Zw/Caj8W6mo oGHgNveRQ1g9FYn3NUp7UvS22Zt/KW4pCpbgkQZefxupKO6QVNwwggV44cTQ37z5onGbNPD8 +2k2mmC0OEtGBkj+VH39tRk+uLOcuXlGNSVk3xOyxni0Nk9M0GvTvPKoah9gkvL/+AofN/31 ABEBAAHCwWUEGAECAA8CGwwFAle9yxIFCQPB+zAACgkQFnkrTqJTQPggQRAAhTX+TRu+M47v 5OzzPUNv+nW70MZQMIXkf4NueFyiPGyad44fNxC0gsmbQVIswPOxfqH0VSpil03iyTXzkI+y o0BdGfKO8fZ1PT70ZJkaj1t6tIBP17gM3VjftxNcYCwOnGgyDoODAb/8mF6oQZJ3JjOCVj8m wYk59/1cvjVffKzFhnkrPU+Xojz0ut7fy2uvrkzyx5bx/dD2x9Ft/YdFtGOceLLCnK4vET2E 4htjNVhSBWtSvxqv5uMJMAyN1UfG4BDMPNXPH80uSHjk2rpOb9yG6rQmdN64ZIIE/zCRAJ/s NCNiwq7UGZijRXMqt16qDelcqtQZMlIf+MU6pQpoiIZg1WKl6bZg8qPg8PW7xMxJcaraNka0 ajOzg2FzJxBfAIno4qaze8G5BMhud+MuA4ihXTphFolKuk9qSMpyCSVKakWhWSz2fwBbkLxG IRK/5o0MuU8xKhH9YH3w36lHMWkKWGUd5+YRihdthDljxeIAtr6XgWVKqlFeB3VimfL2fDaW 3w6yUkKfPiZ2rVAkj7Xi1ftJ46CSda0iwFRK+0Qu0aKiBL4aH+gFv6KbQYi81gonIc5DQ2xi txZ/miw3M9PT4/+X+fG5eXgaAhs4E1m+YwOUaHydnuCaK69JemZYiMiWLdZqzicbpAJidHSA ibHNRWhRbl/5Vl7TzYVDjJI=
- Openpgp: preference=signencrypt
- References: <1d8eb765-e147-534e-ed1e-daa8deb8d5a7@arm.com> <f8f51fdf-14a6-b6e0-87b0-5bf0ca8f9394@linaro.org> <02df4e53-258f-ea9c-1381-4420061f7031@arm.com>
On 04/19/2018 01:06 PM, Szabolcs Nagy wrote:
> if these paths are for optimization only then i guess the list
> can change between libc releases without causing issues other
> than performance regressions.
There is a "full lifecycle" cost to turning on multilibs.
In RPM transactions the new libraries are installed and then the old
libraries are removed.
This means that you can have an old multilib'd library present in the
middle of the install, and if you are deprecating the multilib, the
remaining library will be the old one, it may be loaded, and may not
work correctly.
Consider this case:
* Add lse/ search dir if 8.1 LSE.
* Deploy multilibs.
* Deprecate multilib because performance is good enough by default and
you want to stop paying for the build/test/qe costs of two builds.
* Remove multilibs.
At this point all multilib'd packages must deploy a "<package>_post_upgrade"
application which erases all known multilib'd files to avoid loading a
mixed lse/ library with a newer set of libraries. We do this in
glibc via glibc_post_upgrade.c in Fedora [1].
One alternative is to deprecate the lse/ search dir immediately in ld.so,
which is not always desirable because some applications may still be
relying on it to load/operate correctly.
So think carefully before turn on multilibs. The additional verification
and deployment costs should not be ignored.
As a reference, presently in Fedora for POWER we have 4 x ppc64be multilibs,
and only 1 x ppc64le multilib. This is relatively under control because the
ISAs are nested well and Fedora has all POWER8 builders (the latest multilib).
--
Cheers,
Carlos.
[1] https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc_post_upgrade.c