This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] Avoid the use of mmap as buffer for stdio streams
- From: Arjan van de Ven <arjan at linux dot intel dot com>
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 27 Nov 2006 23:18:20 +0100
- Subject: Re: [patch] Avoid the use of mmap as buffer for stdio streams
- References: <4566DE80.7050207@linux.intel.com> <456B5FE6.4060603@redhat.com>
Ulrich Drepper wrote:
What code is _really_ affected by this?
I noticed it while stracing the new version of irqbalance that I'm
developing. That needs to fopen/read/fclose 3 virtual (proc/sysfs)
files every iteration; it does the munmap 3 times. I know that a whole
lot of the desktop stack (hal, gnome-power-manager etc) do this as
well, adding up to a few dozen such things every second.
Many of the "traditional" unix tools like tar and grep don't use stdio
so those don't count; that's one point for your argument.
A case that I found that does count in my favor is nautilus; it uses
stdio for everything and does a lot of fopen .. read some .. fclose
sequences when going into a new directory
(I suspect for reading the first bits of each file to determine what
icon to use)
We are using mmap for a number
of reasons, one of which is that it reduces fragmentation on the heap.
... by trading virtual address space fragmentation some ;)
> It works well and so far I don't see any reason to change this. I've
not seen programs which constantly and with high frequency fclose() files.
I bet if you look at java ...
anyway, one of the things against the mmap implementation is that it
allocates 4K for a buffer it uses only 1Kb of. Would you at least
consider changing the default buffer to be PAGE_SIZE if you keep
insisting on using mmap? To avoid the wasting of this 75% of the
memory that's entirely not used....