Re: Downsides to madvise/fadvise(willneed) for application startup

Previous thread: Re: [2.6.31.13] Build failure at arch/x86/kernel/apic/io_apic.c by Tetsuo Handa on Sunday, April 11, 2010 - 9:10 pm. (7 messages)

Next thread: Re: ZTEAC8710 Support with Device ID 0xffff by Greg KH on Sunday, April 11, 2010 - 9:50 pm. (1 message)
From: drepper
Date: Sunday, April 11, 2010 - 9:43 pm

We first need to know the sizes of the segments and their location in the binary.  The binaries we use now are somewhat well laid out.  The read-only segment starts at offset 0 etc.  But this doesn't have to be the case.  The dynamic linker has to be generic.  Also, even if we start mapping at offset zero, now much to map?  The file might contain debug info which must not be mapped.  Therefore the first read loads enough of the headers to make all of the decisions.  Yes, we could do a mmap of one page instead of the read.  But that's more expansive in general, isn't it?
From: Taras Glek
Date: Sunday, April 11, 2010 - 9:46 pm

Can this not be cached for prelinked files? I think it is reasonable to 
optimize the gnu dynamic linker to optimize for an optimal layout 
produced by gnu tools of the same generation.

Taras
--

From: Wu Fengguang
Date: Sunday, April 11, 2010 - 9:50 pm

Right. Without considering IO, a simple read(512) is more efficient than
mmap()+read+munmap().

Thanks,
Fengguang
--

Previous thread: Re: [2.6.31.13] Build failure at arch/x86/kernel/apic/io_apic.c by Tetsuo Handa on Sunday, April 11, 2010 - 9:10 pm. (7 messages)

Next thread: Re: ZTEAC8710 Support with Device ID 0xffff by Greg KH on Sunday, April 11, 2010 - 9:50 pm. (1 message)