Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How setting the TZ environment variable avoids thousands of system calls

blog.packagecloud.io

Post reply on HN
Print view View original

91–100 of 148 posts

Re: How setting the TZ environment variable avoids thousands of system calls

#91

Post by __jal »

peterwwillis wrote: post #26
tytso wrote: post #18

System calls in Linux are really fast. So saving "thousands" of system calls when /etc/localtime is in cache doesn't actually save that much actual CPU time. I ran an experiment where I timed the runtime of the sample program provided in the OP, except I changed the number of calls to localtime() from ten times to a million. I then timed the difference with and without export TZ=:/etc/localhost. The net savings was .…

Yeah, this is a perfect example of micro-optimization being unnecessary. Not only will you not see performance issues from this in the real world, it might cause problems down the road, because since it isn't set by default this way, some apps may not expect it and behave erroneously. But it's neat information to have in the back of your head.

That's just not possible to authoritatively state. The best you can do is "this shouldn't normally cause a noticeable impact on most systems".

As just one example, what you're stat()ing over NFS with a busy, flaky and/or distant server? A bit of thought and you'll come up with a bunch of other times it suddenly starts to matter.

Re: How setting the TZ environment variable avoids thousands of system calls

#92

Post by Dylan16807 »

gumby wrote: post #60
cbsmith wrote: post #55

This reads to me like a glibc bug. Glibc should just be watching "/etc/localtime" for changes, rather than calling out to hundreds of times a second.

And how does it watch it? With the stat() syscall.

Polling is not watching.

Re: How setting the TZ environment variable avoids thousands of system calls

#93

Post by caf »

actuator wrote: post #58

While trying to find the cause of slowness in Rails requests, I was running strace on an unicorn process when I encountered the same thing mentioned in the article. Rails instrumentation code calls current time before and after any instrumentation block. So, when I looked at the trace there were a lot of `stat` calls coming for `/etc/localtime` and as stat is an IO operation, I thought I discovered the cause of slown…

...while the call count was high, the time taken by the calls in total was not significant(

Yes, on ordinary filesystems if you run stat() over and over again on the same file then it's just copying from the in-memory inode into your struct stat, there's no IO.

Re: How setting the TZ environment variable avoids thousands of system calls

#94

Post by btown »

koverstreet wrote: post #70
andrewbinstock wrote: post #59

Earlier quoted context omitted.

Those who don't know George Santayana are condemned to repeat him. FTFY.

You seem to have missed the joke...

You seem to have missed the joke... wait a second...

Re: How setting the TZ environment variable avoids thousands of system calls

#95

Post by acscott »

This reminds me of setting noatime for disk mounts (http://askubuntu.com/questions/2099/is-it-worth-to-tune-ext4...)

Now I want to know the number of other configs to reduce the number of system calls. This all adds up to being significant the greater the number of hosts in your environment.

Re: How setting the TZ environment variable avoids thousands of system calls

#96

Post by cbsmith »

noselasd wrote: post #61
cbsmith wrote: post #55

This reads to me like a glibc bug. Glibc should just be watching "/etc/localtime" for changes, rather than calling out to hundreds of times a second.

There's no usable mechanisms glibc can use for watching /etc/localtime for changes that does not mess up the program if it also decides to use any file watching features.

At least on key platforms, it's pretty easy to use an event driven model and watch for updates. Hell, if the vDSO handled TZ it'd be no problem.

Re: How setting the TZ environment variable avoids thousands of system calls

#97

Post by codedokode »

tytso wrote: post #45
rpcope1 wrote: post #29

Earlier quoted context omitted.

This might be true for your system and libc, where the system calls make use of things like vDSO for gettimeofday go fast, but in general this isn't guaranteed at all. Even on x64, for certain libc implementations, like musl, if I recall correctly, syscalls are made the old fashioned way by trapping 0x80, which would mean you would see a much bigger effect by reducing the number of syscalls.

There is no vDSO for calls to stat(2). The claim in the article was that by setting the TZ environment variable to ":/etc/localtime", one could save "thousands" of stat system calls. Even for old-fashioned system calls where you use trap 0x80, Linux is still amazingly fast. This can actually be a problem, since there are applications like git which assume stat is fast, and so it aggressively stat's all of the working…

Does Windows has stat() call? It is probably a function from some POSIX emulation layer and maybe that is why it is not fast.

Re: How setting the TZ environment variable avoids thousands of system calls

#98

Post by amluto »

philsnow wrote: post #77
raverbashing wrote: post #53

Earlier quoted context omitted.

System calls in x86 are fast. Other archs behave differently. And the syscall time is not the only thing that matters, but potentially yielding execution

I thought they were fast because x86 has multiple register files, enough for kernel space and user space to have their own, so that entry/exit to system calls doesn't require flushing registers to L1 (in the common case). If that's true, then one test where you have a single process spinning into and out of a single syscall will have very different performance characteristics than a test where you have more processes…

They're fast because x86 has a decently fast privilege change mechanism for system calls and Linux works fairly hard to avoid doing unnecessary work to handle them. In the simplest case, registers are saved, a function is called, regs are restored, and the kernel switches back to user mode.

The asm code is fairly straightforward in Linux these days. I'm proud of it. :)

Re: How setting the TZ environment variable avoids thousands of system calls

#99

Post by brendangregg »

Please quantify the speedup (I've found this before, but it's never been a significant issue). Eliminating unnecessary work is great, but what are we really talking about here? Use a CPU flamegraph, Ctrl-F and search for stat functions. It'll quantify the total on the bottom right.

Re: How setting the TZ environment variable avoids thousands of system calls

#100

Post by brendangregg »

brendangregg wrote: post #99

Please quantify the speedup (I've found this before, but it's never been a significant issue). Eliminating unnecessary work is great, but what are we really talking about here? Use a CPU flamegraph, Ctrl-F and search for stat functions. It'll quantify the total on the bottom right.

Oh, and another page that recommends strace without warning about overheads. Dangerous.
Post reply on HN