public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Al Boldi <a1426z@gawab.com>
Cc: Dmitry Krivoschekov <dmitry.krivoschekov@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Execute in place
Date: Mon, 07 May 2007 12:41:23 -0700	[thread overview]
Message-ID: <463F80E3.8020204@zytor.com> (raw)
In-Reply-To: <200705072237.33217.a1426z@gawab.com>

Al Boldi wrote:
> H. Peter Anvin wrote:
>> Al Boldi wrote:
>>> Isn't everything really just temporary?
>>>
>>> Would something like an mmap'd tmpfs be possible?
>> No.  tmpfs relies on being able to leave data structures in the running
>> kernel.  In particular, it has no metadata store at all.
>>
>> The needs for a persistent filesystem are very different, regardless of
>> what the underlying medium is.
> 
> Think Suspend-To-Disk; in that case tmpfs looks pretty persistent to me.
> 
> So what does STD do?  It pushes memory out to swap.

It pushes ALL of (used) memory out to swap.

> Now, tmpfs could probably do the same thing on its own either to a private 
> swap or an mmap.  I am suggesting mmap, as swap is currently really slow 
> with tmpfs, and switching it to use mmap may buy us 2 for the price of 1.

No.

First of all, it would have to map ALL of kernel memory, or you would
have to change the way things like dentries, inodes, and namespaces are
allocated in the kernel itself.

Second, you still would have no stability across kernel versions.

Third, you would have to accept total data loss on unclean shutdown,
because tmpfs doesn't care about coherency, *NOR SHOULD IT*.  This is
the fundamental reason why allocating a large swap partition and making
/tmp a tmpfs can give a *huge* performance boost, even though it still
hits disk.

What you're talking about is, *and should be*, a different filesystem.
You will relatively quickly find that you have to deal with the same
kind of stuff that you have to in any filesystem.

	-hpa

  reply	other threads:[~2007-05-07 19:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-02 23:11 Execute in place Al Boldi
2007-05-03  7:31 ` Dmitry Krivoschekov
2007-05-03 11:33   ` Al Boldi
2007-05-03 17:38     ` Dmitry Krivoschekov
2007-05-07 16:46     ` H. Peter Anvin
2007-05-07 19:37       ` Al Boldi
2007-05-07 19:41         ` H. Peter Anvin [this message]
2007-05-07 20:56           ` Al Boldi
2007-05-08  6:06             ` H. Peter Anvin
2007-05-08 11:36               ` Al Boldi
2007-05-08 11:37                 ` H. Peter Anvin
2007-05-08 12:02                   ` Al Boldi
  -- strict thread matches above, loose matches on Subject: below --
2007-05-01 21:55 Phillip Susi
2007-05-02 14:04 ` Hugh Dickins
2007-05-02 14:38   ` Björn Steinbrink
2007-05-02 15:22     ` Hugh Dickins
2007-05-02 19:30       ` Phillip Susi
2007-05-02 20:34         ` Hugh Dickins
2007-05-03 11:38   ` Erik Mouw
2007-05-03 15:37     ` Jörn Engel
2007-05-03 12:12   ` Robin Getz

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=463F80E3.8020204@zytor.com \
    --to=hpa@zytor.com \
    --cc=a1426z@gawab.com \
    --cc=dmitry.krivoschekov@gmail.com \
    --cc=linux-kernel@vger.kernel.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