This is the mail archive of the
mailing list for the glibc project.
Re: advise on future of glibc (mktime issue)
On Tue, Jun 07, 2005 at 11:02:54AM -0400, Jairo19@interhosting.us wrote:
> 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
> >>still faster.
> >>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
> >>system ?
> >> 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?