This is the mail archive of the
mailing list for the glibc project.
Re: advise on future of glibc (mktime issue)
H. J. Lu wrote:
On Tue, Jun 07, 2005 at 11:02:54AM -0400, Jairo19@interhosting.us wrote: Hola:
H. J. Lu wrote:
On Tue, Jun 07, 2005 at 10:35:48AM -0400, Jairo19@interhosting.us wrote:Hola:
This seems to be the right mailing list for this message, please let
me know otherwise.
We recently ran into some problems, and their root lies in glibc.
I will ask my questions first, then I will elaborate on the problem.
1.- What is the relationship between RedHat and glibc (besides
hosting the project)?,
2.- do RH patches make it to the general glibc releases ?, does this
mean that eventually other Linux distributions will get those changes ?
(I think the answer to the second part is almost an obvious YES, but I
have to ask)
3.- do other developers besides redhat's have the chance to
review/approve RH's changes before the make it to the main tree ?
We found our problem when migrating from RH7.3 to RHEL4 and FC3. Our
application slowed down significantly, a process that takes 1 day in
RH7.3 now takes 3-4 days in FC3 and RHEL4.
After debugging I see the problem shows up because we call millions
of times mktime (no way to avoid that for us). The patched glibc (I
think by RH) has mktime checking for changes on the system's timezone,
this is done by checking the file: /etc/localtime which is either a link
or a copy of the local timezone file from /usr/share/zoneinfo, this is a
call to the file system via stat64(), hence our program is accessing
millions of times the file system and crawling in pain. The old glibc,
used in RH7.3 and used in Suse Enterprise 9 does not check for changes
to this file with every call to mktime.
I was able to eliminate the checks by temporarily setting TZ to GMT,
but as I understand that is no longer suggested/supported, and RH7.3 was
I contacted RH and they say they will not change the behavior of their
glibc because they prefer "correctness over performance" and they
believe glibc should be checking for changes to the timezone. Their
suggestions are: build our own glibc and loose RH support, rewrite
mktime for our own use (I tried that but seemed a little complicated and
looses the benefit of the library per se), and lastly they suggested to
set TZ=/etc/localtime (which makes the program run a little faster, but
not as fast as RH7.3).
It is widely known that FC1,2,3 and RHEL* are slow systems, and I
always figured it was for the better, then I question, how may of this
little changes in glibc exists in RH's patches that by themselves may
not be a big performance hit, but put them together and you get a slower
So our solution could be to migrate to another Linux platform, but if
the changes that RH made are going to show up in the library anyway, we
would be just delaying the problem.
My little and simple program that shows the performance hit (I'm
leaving all the includes that my main program uses):
Are you 100% sure that mktime is the only cause of slowdown in your
application on RHEL 4? If it is the case, it shouldn't be too hard
to work around it.
Thanks for your reply.
I take the same program and remove the calls to mktime and the
program runs considerably faster, no doubt about it. Even without the
call to mktime, RH7.3 is also faster than RHEL4.
That is what I am thinking.
What do you suggest ?
Have you disabled SELinux? Did you recompile your program on RHEL 4?
Can you run your program, which was compiled on RH 7.3, on RHEL 4? Have
you compared oprofile/vtune results between RH 7.3 and RHEL 4? BTW,
what hardware configuration are you using?
I did not disable SELinux for my general tests, I may have done it
for one of my initial tests when learning about the issue.
Yes, I ran recompiled version of the program as well as the original
7.3 version, because the library is shared, the RH7.3 version loads the
Shared library in RHEL4 and it calls slow library.
I am not familiar with oprofile/vtune, but I used strace, and the
output of strace shows the millions of calls to stat64("/etc/localtime")
how would they help me ?
I tested this on Dual Athlons and a new Dual XEON machine. All with
1 Gig of RAM.