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]
Message-Id: <200706301758.16607.a1426z@gawab.com>
Date:	Sat, 30 Jun 2007 17:58:16 -0400
From:	Al Boldi <a1426z@...ab.com>
To:	peter@...bb.wattle.id.au
Cc:	Christoph Hellwig <hch@...radead.org>,
	Jared Hulbert <jaredeh@...il.com>,
	Nick Piggin <npiggin@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: vm/fs meetup in september?

peter@...bb.wattle.id.au wrote:
> >>>>> "Christoph" == Christoph Hellwig <hch@...radead.org> writes:
>
> Christoph> On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert
>
> Christoph> wrote:
> >> If you have a large array of a non-volatile semi-writeable memory
> >> such as a highspeed NOR Flash or some of the similar emerging
> >> technologies in a system.  It would be useful to use that memory as
> >> an extension of RAM.  One of the ways you could do that is allow
> >> pages to be swapped out to this memory.  Once there these pages
> >> could be read directly, but would require a COW procedure on a
> >> write access.  The reason why I think this may be a vm/fs topic is
> >> that the hardware makes writing to this memory efficiently a
> >> non-trivial operation that requires management just like a
> >> filesystem.  Also it seems to me that there are probably overlaps
> >> between this topic and the recent filemap_xip.c discussions.
>
> Christoph> So what you mean is "swap on flash" ?  Defintively sounds
> Christoph> like an interesting topic, although I'm not too sure it's
> Christoph> all that filesystem-related.

I wouldn't want to call it swap, as this carries with it block-io 
connotations.  It's really mmap on flash.

> You need either a block translation layer,

Are you suggesting to go through the block layer to reach the flash?

> or a (swap) filesystem that
> understands flash peculiarities in order to make such a thing work.
> The standard Linux swap format will not work.

Correct.

BTW, you may want to have a look at my "[RFC] VM: I have a dream..." thread.

Here is an excerpt:

"What's more, there is no more swap.
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."

The thread ended with this conclusion:

Alan Cox wrote:
> On Iau, 2006-02-02 at 21:59 +0300, Al Boldi wrote:
> > So w/ 1GB RAM, no swap, and 1TB disk mmap'd, could this mmap'd space be
> > added to the total memory available to the OS, as is done w/ swap?
>
> Yes in theory. It would be harder to manage.
>
> > And if that's possible, why not replace swap w/ mmap'd disk-space?
>
> Swap is just somewhere to stick data that isnt file backed, you could
> build a swapless mmap based OS but it wouldn't be quite the same as
> Unix/Linux are.


Thanks!

--
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ