Re: [gentoo-dev] Defining TZ in the base system profile?
On Wed, Jan 18, 2023 at 08:48:56PM -0500, Joshua Kinard wrote: > > So this article[1] from 2017 popped up again on the tech radar via > hackernews[2] and a few other sites[3]. It > annotates how if the envvar TZ is undefined on a Linux system, it causes > glibc to generate a number of > additional syscalls, mainly stat-related calls (in my tests, newfstatat()). > If defined to an actual value, > such as ":/etc/localtime" (or even an empty string), glibc will instead > generate far fewer, if any at all, of > these stat-related syscalls. [...] > > Thoughts? Sounds good to me from the little I know of it, albeit I do imagine it could raise issues with some packages that try to use/handle TZ themselves and no telling what obscure thing this is going to break. exa[1][2] is one example that sam mentioned, but I imagine there's more to find. Personally added to /etc/env.d locally anyway, will see what come of it for the things I use, not that this covers much at all :) [1] https://github.com/ogham/exa/issues/856 [2] https://github.com/ogham/exa/pull/867 -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] Defining TZ in the base system profile?
On Wed, 2023-01-18 at 20:48 -0500, Joshua Kinard wrote: > So this article[1] from 2017 popped up again on the tech radar via > hackernews[2] and a few other sites[3]. It > annotates how if the envvar TZ is undefined on a Linux system, it causes > glibc to generate a number of > additional syscalls, mainly stat-related calls (in my tests, newfstatat()). > If defined to an actual value, > such as ":/etc/localtime" (or even an empty string), glibc will instead > generate far fewer, if any at all, of > these stat-related syscalls. > > [...] > So is adding a default definition of TZ to our base system /etc/profile > something we want to look at? I > haven't tried any other methods of benchmarking to see if not making those > additional syscalls is just placebo > or if there are actual impacts. Given how long this oddity has been around, > I can't tell if it's a genuine > bug in glibc, an unoptimized corner case, or just a big nothingburger. > Am I correct that there's no real difference between setting it to ":/etc/localtime" and the actual timezone? I suppose it would make sense to default it. -- Best regards, Michał Górny
[gentoo-dev] Defining TZ in the base system profile?
So this article[1] from 2017 popped up again on the tech radar via hackernews[2] and a few other sites[3]. It
annotates how if the envvar TZ is undefined on a Linux system, it causes glibc to generate a number of
additional syscalls, mainly stat-related calls (in my tests, newfstatat()). If defined to an actual value,
such as ":/etc/localtime" (or even an empty string), glibc will instead generate far fewer, if any at all, of
these stat-related syscalls.
Apparently, TZ is accessed quite frequently, so this has a compound effect, according to the article, in glibc
making thousands of unnecessary stat-related syscalls to /etc/localtime (which must be hard-coded somewhere in
glibc for this case). Given the article's age (five years old), I tested the example C program out, and it
does appear to still be accurate on a modern glibc-based system. When TZ is undefined, I get exactly nine
newfstatat calls on /etc/localtime. If I define TZ to ":/etc/localtime", I do not get any of these newfstatat
calls, and if I set TZ to an empty string, glibc will call openat() against "/usr/share/zoneinfo/Universal"
and then generate exactly two newfstatat syscalls on that handle to read it.
I ran strace() against the undefined TZ case and the ":/etc/localtime" case, normalized the hex addresses to
get a clean diff, and this is what it looks like:
--- a 2023-01-18 20:30:36.826805343 -0500
+++ b 2023-01-18 20:30:45.106983600 -0500
@@ -1,4 +1,4 @@
-# strace ./tz_test
+# TZ=":/etc/localtime" strace ./tz_test
execve("./tz_test", ["./tz_test"], 0x /* XX vars */) = 0
brk(NULL) = 0x
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x
@@ -61,15 +61,6 @@ read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0
lseek(3, -2260, SEEK_CUR) = 1292
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\6\0\0\0\0"...,
3584) = 2260
close(3)= 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
-newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=3552, ...}, 0) = 0
write(1, "Godspeed, dear friend!\n", 23Godspeed, dear friend!
) = 23
exit_group(0) = ?
For comparison, I tested the same program on FreeBSD and it does not exhibit this behavior at all, regardless
of whether TZ is undefined, a value, or an empty string. I have yet to make a similar test on a mips/musl
chroot to see how musl handles this.
There is a rather old (2010) StackOverflow question[4] about it as well, and someone left an answer in March
of last year about the specific code in glibc that handles TZ if it is set or is an empty string.
So is adding a default definition of TZ to our base system /etc/profile something we want to look at? I
haven't tried any other methods of benchmarking to see if not making those additional syscalls is just placebo
or if there are actual impacts. Given how long this oddity has been around, I can't tell if it's a genuine
bug in glibc, an unoptimized corner case, or just a big nothingburger.
1.
https://blog.packagecloud.io/set-environment-variable-save-thousands-of-system-calls/
2. https://news.ycombinator.com/item?id=34346346
3. https://vermaden.wordpress.com/posts/
4.
https://stackoverflow.com/questions/4554271/how-to-avoid-excessive-stat-etc-localtime-calls-in-strftime-on-linux
Thoughts?
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by
moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
[gentoo-dev] Packages up for grabs: app-dicts/myspell-en, app-dicts/myspell-large-en, dev-python/aiohttp-cors, x11-misc/copyq
The following packages are up for grabs due to the retirement of their proxied maintainer: app-dicts/myspell-en app-dicts/myspell-large-en dev-python/aiohttp-cors x11-misc/copyq Thank you, Viorel
Re: [gentoo-dev] Deprecating virtual/opengl in favor of media-libs/libglvnd
On Wed, Jan 18, 2023 at 05:37:03AM -0800, orbea wrote: > I think this is a mistake, libglvnd has a documented performance hit > and should be optional. Optional glvnd was a complete mess and this isn't happening. Also, performance impact is only relevant if cpu-bound which is rather rare for normal games and applications (aka, not stuff like glxgears). "some" emulators can be more cpu-bound, but a lot of the bigger ones support vulkan anyway nowadays. Yes, there are cases where it'd be better but we're way too far from it being worth the maintenance cost and confusion. Recently seen people run into issues with libEGL when forcing -Dglvnd=false too, more things to worry about. > > https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/222 > > On Wed, 18 Jan 2023 14:23:22 +0200 > Cedric Sodhi wrote: > > > Hello everyone, > > > > as by our discussion on #gentoo-desktop, we would like to sort out > > the historical artefact "virtual/opengl" which dates back to before > > Wayland and has become somewhat inappropriate (a misnomer, not > > sufficiently configurable, or redundant depending on one's > > perspective). > > > > A quick recap of the situation, a description of the problems and > > reasons why it should be deprecated, as well as the "way forward" are > > documented here: > > > > https://wiki.gentoo.org/wiki/User:ManDay/Deprecating_the_virtual_OpenGL_ebuild > > > > At this point we would like to invite everyone to enter additional > > feedback - including potential problems which are not covered by the > > article. When we're sure that everything has been considered, we can > > move to deprecating "virtual/opengl". > > > > > > Thank you! > > Cedric > > > > -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating virtual/opengl in favor of media-libs/libglvnd
I think this is a mistake, libglvnd has a documented performance hit and should be optional. https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/222 On Wed, 18 Jan 2023 14:23:22 +0200 Cedric Sodhi wrote: > Hello everyone, > > as by our discussion on #gentoo-desktop, we would like to sort out > the historical artefact "virtual/opengl" which dates back to before > Wayland and has become somewhat inappropriate (a misnomer, not > sufficiently configurable, or redundant depending on one's > perspective). > > A quick recap of the situation, a description of the problems and > reasons why it should be deprecated, as well as the "way forward" are > documented here: > > https://wiki.gentoo.org/wiki/User:ManDay/Deprecating_the_virtual_OpenGL_ebuild > > At this point we would like to invite everyone to enter additional > feedback - including potential problems which are not covered by the > article. When we're sure that everything has been considered, we can > move to deprecating "virtual/opengl". > > > Thank you! > Cedric >
[gentoo-dev] Deprecating virtual/opengl in favor of media-libs/libglvnd
Hello everyone, as by our discussion on #gentoo-desktop, we would like to sort out the historical artefact "virtual/opengl" which dates back to before Wayland and has become somewhat inappropriate (a misnomer, not sufficiently configurable, or redundant depending on one's perspective). A quick recap of the situation, a description of the problems and reasons why it should be deprecated, as well as the "way forward" are documented here: https://wiki.gentoo.org/wiki/User:ManDay/Deprecating_the_virtual_OpenGL_ebuild At this point we would like to invite everyone to enter additional feedback - including potential problems which are not covered by the article. When we're sure that everything has been considered, we can move to deprecating "virtual/opengl". Thank you! Cedric -- - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!
