From: Andrew Morton <akpm@linux-foundation.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables
Date: Tue, 18 Mar 2008 00:36:20 -0700 [thread overview]
Message-ID: <20080318003620.d84efb95.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080318209.039112899@firstfloor.org>
On Tue, 18 Mar 2008 02:09:34 +0100 (CET) Andi Kleen <andi@firstfloor.org> wrote:
> This patchkit is an experimental optimization I played around with
> some time ago.
>
> This is more a prototype still, but I wanted to push it out
> so that other people can play with it.
>
> The basic idea is that most programs have the same working set
> over multiple runs. So instead of demand paging all the text pages
> in the order the program runs save the working set to disk and prefetch
> it at program start and then save it at program exit.
>
> This allows some optimizations:
> - it can avoid unnecessary disk seeks because the blocks will be fetched in
> sorted offset order instead of program execution order.
> - batch kernel entries (each demand page exception has some
> overhead just for entering the kernel). This keeps the caches hot too.
> - The prefetch could be in theory done in the background while the program
> runs (although that is not implemented currently)
Should be worthwhile for some things.
> Some details on the implementation:
Can't this all be done in userspace? Hook into exit() with an LD_PRELOAD,
use /proc/self/maps and the new pagemap code to work out which pages of
which files were faulted in, write that info into the elf file (or a
separate per-executable shadow file), then use that info the next time the
app is executed, either with an LD_PRELOAD or just a wrapper.
> Drawbacks:
> - No support for dynamic libraries right now (except very clumpsily
> through the mmap_slurp hack). This is the main reason it is not
> very useful for speed up desktops currently.
>
> - Executable files have to be writable by the user executing it
> currently to get bitmap updates. It would be possible to let the
> kernel bypass this, but I haven't thought too much about the security
> implications of it.
> However any user can use the bitmap data written by a user with
> write rights.
Those all get fixed with the userspace version?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF executables
Date: Tue, 18 Mar 2008 00:36:20 -0700 [thread overview]
Message-ID: <20080318003620.d84efb95.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080318209.039112899@firstfloor.org>
On Tue, 18 Mar 2008 02:09:34 +0100 (CET) Andi Kleen <andi@firstfloor.org> wrote:
> This patchkit is an experimental optimization I played around with
> some time ago.
>
> This is more a prototype still, but I wanted to push it out
> so that other people can play with it.
>
> The basic idea is that most programs have the same working set
> over multiple runs. So instead of demand paging all the text pages
> in the order the program runs save the working set to disk and prefetch
> it at program start and then save it at program exit.
>
> This allows some optimizations:
> - it can avoid unnecessary disk seeks because the blocks will be fetched in
> sorted offset order instead of program execution order.
> - batch kernel entries (each demand page exception has some
> overhead just for entering the kernel). This keeps the caches hot too.
> - The prefetch could be in theory done in the background while the program
> runs (although that is not implemented currently)
Should be worthwhile for some things.
> Some details on the implementation:
Can't this all be done in userspace? Hook into exit() with an LD_PRELOAD,
use /proc/self/maps and the new pagemap code to work out which pages of
which files were faulted in, write that info into the elf file (or a
separate per-executable shadow file), then use that info the next time the
app is executed, either with an LD_PRELOAD or just a wrapper.
> Drawbacks:
> - No support for dynamic libraries right now (except very clumpsily
> through the mmap_slurp hack). This is the main reason it is not
> very useful for speed up desktops currently.
>
> - Executable files have to be writable by the user executing it
> currently to get bitmap updates. It would be possible to let the
> kernel bypass this, but I haven't thought too much about the security
> implications of it.
> However any user can use the bitmap data written by a user with
> write rights.
Those all get fixed with the userspace version?
--
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-18 7:37 UTC|newest]
Thread overview: 82+ 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 ` Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [1/8] Give ELF shdr types a name Andi Kleen
2008-03-18 1:09 ` 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 ` 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 ` 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 ` Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [5/8] Add ELF constants for pbitmaps Andi Kleen
2008-03-18 1:09 ` Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [6/8] Core predictive bitmap engine Andi Kleen
2008-03-18 1:09 ` Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [7/8] Add the sysctls to control pbitmaps Andi Kleen
2008-03-18 1:09 ` Andi Kleen
2008-03-18 1:09 ` [PATCH prototype] [8/8] Add mmap_full_slurp support Andi Kleen
2008-03-18 1:09 ` Andi Kleen
2008-03-18 7:36 ` Andrew Morton [this message]
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 14:18 ` Andi Kleen
2008-03-18 16:57 ` Andrew Morton
2008-03-18 16:57 ` Andrew Morton
2008-03-18 17:20 ` Andi Kleen
2008-03-18 17:20 ` Andi Kleen
2008-03-18 17:44 ` Andrew Morton
2008-03-18 17:44 ` Andrew Morton
2008-03-19 8:32 ` Andi Kleen
2008-03-19 8:32 ` Andi Kleen
2008-03-19 9:04 ` Andrew Morton
2008-03-19 9:04 ` Andrew Morton
2008-03-19 22:45 ` Ulrich Drepper
2008-03-19 22:45 ` Ulrich Drepper
2008-03-19 23:12 ` Andrew Morton
2008-03-19 23:12 ` Andrew Morton
2008-03-20 0:09 ` David Miller
2008-03-20 0:09 ` David Miller, Andrew Morton
2008-03-20 9:00 ` Andi Kleen
2008-03-20 9:00 ` Andi Kleen
2008-03-21 17:15 ` Ulrich Drepper
2008-03-21 17:15 ` Ulrich Drepper
2008-03-21 17:26 ` Andi Kleen
2008-03-21 17:26 ` Andi Kleen
2008-03-22 4:36 ` Ulrich Drepper
2008-03-22 4:36 ` Ulrich Drepper
2008-03-22 7:17 ` Andi Kleen
2008-03-22 7:17 ` Andi Kleen
2008-03-22 7:24 ` Nicholas Miell
2008-03-22 7:24 ` Nicholas Miell
2008-03-22 9:10 ` Andi Kleen
2008-03-22 9:10 ` Andi Kleen
2008-03-22 10:16 ` Nicholas Miell
2008-03-22 10:16 ` Nicholas Miell
2008-03-22 14:29 ` Andi Kleen
2008-03-22 14:29 ` Andi Kleen
2008-03-23 13:25 ` Pavel Machek
2008-03-23 13:25 ` Pavel Machek
2008-03-23 17:08 ` Andi Kleen
2008-03-23 17:08 ` Andi Kleen
2008-03-24 16:24 ` Pavel Machek
2008-03-24 16:24 ` Pavel Machek
2008-03-24 4:20 ` Ulrich Drepper
2008-03-24 4:20 ` Ulrich Drepper
2008-03-24 5:16 ` Nicholas Miell
2008-03-24 5:16 ` Nicholas Miell
2008-03-24 5:26 ` Andi Kleen
2008-03-24 5:26 ` Andi Kleen
2008-03-24 19:42 ` Ulrich Drepper
2008-03-24 19:42 ` Ulrich Drepper
2008-03-24 21:47 ` Nicholas Miell
2008-03-24 21:47 ` Nicholas Miell
2008-03-25 7:54 ` Andi Kleen
2008-03-25 7:54 ` Andi Kleen
2008-03-26 18:15 ` Ulrich Drepper
2008-03-26 18:15 ` Ulrich Drepper
2008-03-26 18:54 ` Andi Kleen
2008-03-26 18:54 ` Andi Kleen
2008-03-22 4:38 ` Ulrich Drepper
2008-03-22 4:38 ` Ulrich Drepper
2008-03-20 0:15 ` Diego Calleja
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=20080318003620.d84efb95.akpm@linux-foundation.org \
--to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.