This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Avoid the use of mmap as buffer for stdio streams


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....



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]