From: "Ulrich Drepper" <drepper@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables
Date: Wed, 19 Mar 2008 15:45:16 -0700 [thread overview]
Message-ID: <a36005b50803191545h33d1a443y57d09176f8324186@mail.gmail.com> (raw)
In-Reply-To: <20080319020440.80379d50.akpm@linux-foundation.org>
On Wed, Mar 19, 2008 at 2:04 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> The requirement to write to an executable sounds like a bit of a
> showstopper.
Agreed. In addition, it makes all kinds of tools misbehave. I can
see extensions to the ELF format and those would require relinking
binaries, but without this you create chaos. ELF is so nice because
it describes the entire file and we can handle everything according to
rules. If you just somehow magically patch some new data structure in
this will break things.
Furthermore, by adding all this data to the end of the file you'll
normally create unnecessary costs. The parts of the binaries which
are used at runtime start at the front. At the end there might be a
lot of data which isn't needed at runtime and is therefore normally
not read.
> if it proves useful, build it all into libc..
I could see that. But to handle it efficiently kernel support is
needed. Especially since I don't think the currently proposed
"learning mode" is adequate. Over many uses of a program all kinds of
pages will be needed. Far more than in most cases. The prefetching
should really only cover the commonly used code paths in the program.
If you pull in everything, this will have advantages if you have that
much page cache to spare. In that case just prefetching the entire
file is even easier. No, such an improved method has to be more
selective.
But if we're selective in the loading of the pages we'll
(unfortunately) end up with holes. Possibly many of them. This would
mean with today's interfaces a large number of madvise() calls. What
would be needed is kernel support which takes a bitmap, each bit
representing a page. This bitmap could be allocated as part of the
binary by the linker. With appropriate ELF data structures supporting
it so that strip et.al won't stumble. To fill in the bitmaps one can
have separate a separate tool which is explicitly asked to update the
bitmap data. To collect the page fault data one could use systemtap.
It's easy enough to write a script which monitors the minor page
faults for each binary and writes the data into a file. The binary
update tool and can use the information from that file to generate the
bitmap.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-03-19 22:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-18 1:09 [PATCH prototype] [0/8] Predictive bitmaps for ELF executables Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [1/8] Give ELF shdr types a name Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [2/8] Add support to override mmap exec write protection with O_FORCEWRITE Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [3/8] Make readahead max pinned value a sysctl Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [4/8] Add readahead function to read-ahead based on a bitmap Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [5/8] Add ELF constants for pbitmaps Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [6/8] Core predictive bitmap engine Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [7/8] Add the sysctls to control pbitmaps Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [8/8] Add mmap_full_slurp support Andi Kleen
2008-03-18 7:36 ` [PATCH prototype] [0/8] Predictive bitmaps for ELF executables Andrew Morton
2008-03-18 14:18 ` Andi Kleen
2008-03-18 16:57 ` Andrew Morton
2008-03-18 17:20 ` Andi Kleen
2008-03-18 17:44 ` Andrew Morton
2008-03-19 8:32 ` Andi Kleen
2008-03-19 9:04 ` Andrew Morton
2008-03-19 22:45 ` Ulrich Drepper [this message]
2008-03-19 23:12 ` Andrew Morton
2008-03-20 0:09 ` David Miller, Andrew Morton
2008-03-20 9:00 ` Andi Kleen
2008-03-21 17:15 ` Ulrich Drepper
2008-03-21 17:26 ` Andi Kleen
2008-03-22 4:36 ` Ulrich Drepper
2008-03-22 7:17 ` Andi Kleen
2008-03-22 7:24 ` Nicholas Miell
2008-03-22 9:10 ` Andi Kleen
2008-03-22 10:16 ` Nicholas Miell
2008-03-22 14:29 ` Andi Kleen
2008-03-23 13:25 ` Pavel Machek
2008-03-23 17:08 ` Andi Kleen
2008-03-24 16:24 ` Pavel Machek
2008-03-24 4:20 ` Ulrich Drepper
2008-03-24 5:16 ` Nicholas Miell
2008-03-24 5:26 ` Andi Kleen
2008-03-24 19:42 ` Ulrich Drepper
2008-03-24 21:47 ` Nicholas Miell
2008-03-25 7:54 ` Andi Kleen
2008-03-26 18:15 ` Ulrich Drepper
2008-03-26 18:54 ` Andi Kleen
2008-03-22 4:38 ` Ulrich Drepper
2008-03-20 0:15 ` Diego Calleja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a36005b50803191545h33d1a443y57d09176f8324186@mail.gmail.com \
--to=drepper@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).