On 04/11/2010 09:43 PM, drepper@gmail.com wrote:
quoted text
> On Sun, Apr 11, 2010 at 19:27, Wu Fengguang <fengguang.wu@intel.com> 
> wrote:
>> Yes, every binary/library starts with this 512b read.  It is requested
>> by ld.so/ld-linux.so, and will trigger a 4-page readahead. This is not
>> good readahead. I wonder if ld.so can switch to mmap read for the
>> first read, in order to trigger a larger 128kb readahead.
>
> 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?
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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/