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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 11 Apr 2010 21:43:00 -0700 (PST)
From:	drepper@...il.com
To:	Wu Fengguang <fengguang.wu@...el.com>
Cc:	Taras Glek <tglek@...illa.com>,
	Johannes Weiner <hannes@...xchg.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Downsides to madvise/fadvise(willneed) for application startup

On Sun, Apr 11, 2010 at 19:27, Wu Fengguang <fengguang.wu@...el.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?

Download attachment "signature.asc" of type "application/pgp-signature" (273 bytes)