linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Al Boldi <a1426z@gawab.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] VM: I have a dream...
Date: Sat, 21 Jan 2006 18:42:19 +0000	[thread overview]
Message-ID: <20060121184219.GA1306@mail.shareable.org> (raw)
In-Reply-To: <200601212108.41269.a1426z@gawab.com>

Al Boldi wrote:
> Apps are executed inplace, as if already loaded.
> Physical RAM is used to cache slower storage RAM, much the same as the CPU 
> cache RAM caches slower physical RAM.

Linux and most other OSes have done that since.. oh, 20 years at least?

It's called "demand paging".  The RAM is simply a cache of the
executable file on disk.  The complicated-looking page fault mechanism
that you see is simply the cache management logic.  In what way is
your vision different from demand paging?

> my memory is equal to total disk-capacity.  What's more, there is no
> more swap.  [...]  Physical RAM is used to cache slower storage RAM,
> much the same as the CPU cache RAM caches slower physical RAM.

Windows has had that since, oh, Windows 95?

It's called "on-demand swap space", or making all the disk's free
space be usable for paging.  The physical RAM is simply a cache of the
virtual "storage RAM".  In what way is your vision different from
on-demand swap?

> Sadly, the current way of dealing with memory can at best only be described 
> as schizophrenic.  Again the reason being, that we are still running in the 
> last-century mode.
>
> Wouldn't it be nice to take advantage of todays 64bit archs and TB drives, 
> and run a more modern way of life w/o this memory/storage split personality?

In what way does your vision _behave_ any differently than what we have?

In my mind, "physical RAM is used to cache slower storage RAM" behaves
the same as demand paging, even if the terminology is different.  The
code I guess you're referring to in the kernel, to handle paging to
storage, is simply one kernel's method of implementing that kind of cache.

It's not clear from anything you said how the computer in your dream
would behave any differently to the ones we've got now.

Can you describe that difference, if there is one?

Is it just an implementation idea, where the kernel does less of the
page caching logic and some bit of hardware does more of it
automatically?  Given how little time is taken in kernel to do that,
and how complex the logic has to be for efficient caching decisions
between RAM and storage, it seems likely that any simple hardware
solution would behave the same, but slower.

-- Jamie

  reply	other threads:[~2006-01-21 18:42 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-21 18:08 [RFC] VM: I have a dream Al Boldi
2006-01-21 18:42 ` Jamie Lokier [this message]
2006-01-21 18:46 ` Avi Kivity
2006-01-23 19:52   ` Bryan Henderson
2006-01-25 22:04     ` Al Boldi
2006-01-26 19:18       ` Bryan Henderson
2006-01-27 16:12         ` Al Boldi
2006-01-27 19:17           ` Bryan Henderson
2006-01-30 13:21             ` Al Boldi
2006-01-30 13:35               ` Kyle Moffett
2006-01-31 15:56                 ` Al Boldi
2006-01-31 16:34                   ` Kyle Moffett
2006-01-31 23:14                     ` Bryan Henderson
2006-01-31 16:34                   ` Lennart Sorensen
2006-01-31 19:23                   ` Jamie Lokier
2006-02-01  4:06                   ` Barry K. Nathan
2006-02-02 15:11                   ` Alan Cox
2006-02-02 18:59                     ` Al Boldi
2006-02-02 22:33                       ` Bryan Henderson
2006-02-03 14:46                       ` Alan Cox
2006-01-30 16:49               ` Bryan Henderson
2006-01-26  0:03     ` Jon Smirl
2006-01-26 19:48       ` Bryan Henderson
2006-01-22  8:16 ` Pavel Machek
2006-01-22 12:33 ` Robin Holt
2006-01-23 18:03   ` Al Boldi
2006-01-23 18:40     ` Valdis.Kletnieks
2006-01-23 19:26       ` Benjamin LaHaise
2006-01-23 19:40         ` Valdis.Kletnieks
2006-01-23 22:26     ` Pavel Machek
2006-01-22 19:55 ` Barry K. Nathan
2006-01-23  5:23   ` Michael Loftis
2006-01-23  5:46     ` Chase Venters
2006-01-23  8:20       ` Barry K. Nathan
2006-01-23 13:17       ` Jamie Lokier
2006-01-23 20:21         ` Peter Chubb
2006-01-23 15:05     ` Ram Gupta
2006-01-23 15:26       ` Diego Calleja
2006-01-23 16:11         ` linux-os (Dick Johnson)
2006-01-23 16:50           ` Jamie Lokier
2006-01-24  2:08           ` Horst von Brand
2006-01-25  6:13             ` Jamie Lokier
2006-01-25  9:23             ` Bernd Petrovitsch
2006-01-25  9:42               ` Lee Revell
2006-01-25 15:02                 ` Jamie Lokier
2006-01-25 23:24                   ` Lee Revell
2006-01-25 15:05               ` Jamie Lokier
2006-01-25 15:47                 ` Bernd Petrovitsch
2006-01-25 16:09                 ` Diego Calleja
2006-01-25 17:26                   ` Jamie Lokier
2006-01-26 19:13                     ` Bryan Henderson
2006-01-25 23:28                 ` Lee Revell
2006-01-26  1:29                   ` Diego Calleja
2006-01-26  5:01                   ` Jamie Lokier
2006-01-26  5:11                     ` Lee Revell
2006-01-26 14:46                       ` Dave Kleikamp
2006-01-24  2:10           ` Horst von Brand
2006-01-25 22:27         ` Nix
2006-01-26 15:13           ` Denis Vlasenko
2006-01-26 16:23             ` Nix
2006-01-23 20:43       ` Michael Loftis
2006-01-23 22:42         ` Nikita Danilov
2006-01-24 14:36           ` Ram Gupta
2006-01-24 15:04             ` Diego Calleja
2006-01-24 20:59               ` Bryan Henderson
2006-01-24 15:11             ` Nikita Danilov
2006-01-23 22:57         ` Ram Gupta
  -- strict thread matches above, loose matches on Subject: below --
2006-02-01 13:58 Al Boldi
2006-02-01 14:38 ` Jamie Lokier
2006-02-02 12:26   ` Al Boldi

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=20060121184219.GA1306@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=a1426z@gawab.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).