This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: advise on future of glibc (mktime issue)
- From: "H. J. Lu" <hjl at lucon dot org>
- To: "Jairo19 at interhosting dot us" <jairo19 at interhosting dot us>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 7 Jun 2005 07:45:47 -0700
- Subject: Re: advise on future of glibc (mktime issue)
- References: <42A5B0C4.7010301@interhosting.us>
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.
H.J.