linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Costless huge virtual memory? /dev/same, /dev/null?
Date: Mon, 29 Feb 2016 17:28:35 +0100	[thread overview]
Message-ID: <20160229162835.GA2816@var.bordeaux.inria.fr> (raw)

Hello,

I'm wondering whether we could introduce a /dev/same device to allow
costless huge virtual memory.

The use case is the simulation of the execution of a big irregular HPC
application, to provision memory usage, cpu time, etc. We know how much
time each computation loop takes, and it's easy to replace them with a
mere accounting. We'd however like to avoid having to revamp the rest
of the code, which does allocation/memcpys/etc., by just replacing
the allocation calls with virtual allocations, i.e. allocations which
return addresses of buffers that one can read/write, but the values you
read are not necessarily what you wrote, i.e. the data is not actually
properly stored (since we don't do the actual computations that's not a
problem).

The way we currently do this is by some folding: we map the same normal
file several times contiguously to form the virtual allocation. By using
a small 1MiB file, this limits memory consumption to 1MiB plus the page
table (and fits the dumb data in a typical cache). This however creates
one VMA per file mapping, we get limited by the 65535 VMA limit, and
VMA lookup becomes slow.

The way I could see is to have a /dev/same device: when you open it, it
allocates one page. When you mmap it, it maps the same page over the
whole resulting single VMA.

This is a quite specific use case, but it seems to be easy to implement,
and it seems to me that it could be integrated mainline. Actually I was
thinking that /dev/null itself could be providing that service?
(currently it returns ENODEV)

What do people think?  Is there perhaps another solution to achieve this
that I didn't think about?

Samuel

--
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>

             reply	other threads:[~2016-02-29 16:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 16:28 Samuel Thibault [this message]
2017-04-13  9:42 ` [RFC] " Samuel Thibault
2017-04-13 16:29   ` Samuel Thibault
2017-04-13 16:34     ` Matthew Wilcox
2017-04-13 17:04       ` Samuel Thibault
2017-04-13 18:37   ` Greg Kroah-Hartman
2017-04-13 18:43     ` Samuel Thibault

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=20160229162835.GA2816@var.bordeaux.inria.fr \
    --to=samuel.thibault@ens-lyon.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