Bug 7150
Summary: | Reporting missing glibc buffering in Redhat 6.0 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | jensen |
Component: | glibc | Assignee: | Cristian Gafton <gafton> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 6.0 | CC: | dowling, jensen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
URL: | www.adobe.com | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-01-05 02:42:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
jensen
1999-11-19 18:21:29 UTC
For additional supporting evidence one can strace the test program. On a 6.1-based system here this shows that the program is actually issuing tiny read() syscalls; on a 5.1-based system the smallest the read() gets is 4096 bytes. The test is completely bogus. libc5 (old libc) is using a buffer size of 1024, whereas glibc is using a buffer size of 8192. There is no compare between the amount of work that the kernel needs to do to read 1024 versus 8192 bytes at a time. Change your test program to use 1024 instead of BUFSIZ for read sizes, and immedately after the fopen() call do a setbuffer(in, buf, 1024) Secondly, the fread in glibc is a thread-safe function, whcih means that it has to go through a lot of stuff to ensure proper locking et all. Use the fread_unlocked is you don't need locking on the IO operations in this test. Once you do that you will see performance aproaching what you have obtained with the old-libc statically compiled binary. It will still be slower (about 25-30%), but that is a far cry from the ten fold times you have got as a result of your test. And considering the added functionality, thread safety and increased complexity of handling a syscall in newer kernels the performance penalty is not bad at all. gafton completely misses the point. The current implementation of glibc is in violation of the ANSI C standard since it does not provide at least BUFSIZ buffering by default. Note that a "workaround" that requires adding code is not acceptable. The program that caused us to notice the problem was gcc! The assertion that "thread-safe" has to be that much slower is just "bogus" and lazy. The point is that the ANSI C standard requires at least BUFSIZ buffering by default. A "workaround" does not resolve the issue at all. We discovered the problem by observing the behavior of gcc and cp! "Thread-safe" performance issues as an excuse is just that, an excuse. Output is buffered by default and if the workaround is used (setvbuf) performance is OK. Is gafton asserting: 1) buffered output is not thread-safe? 2) input with the use of setvbuf is not thread-safe? There are really quite a few problems with the new glibc, not the least of which is its unnecessary intrusions into variable name space, again in violation of the ANSI C standard. |