linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Pavel Machek <pavel@suse.cz>, Andrew Morton <akpm@osdl.org>,
	andrea@suse.de, hugh@veritas.com,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC] sys_punchhole()
Date: Mon, 21 Nov 2005 00:46:44 -0600	[thread overview]
Message-ID: <200511210046.45236.rob@landley.net> (raw)
In-Reply-To: <1132178470.24066.85.camel@localhost.localdomain>

On Wednesday 16 November 2005 16:01, Badari Pulavarty wrote:
> Hmm. Someone other than me asking for it ?
>
> I did the madvise() hack and asking to see if any one really needs
> sys_punchole().

I run into a potential use case for every once in a while.  For example, there 
was recent discussion on the User Mode Linux list about this, since the 
"physical memory" that uses is an mmaped file so the logical way to give 
unused memory back to the host OS (initially via a hotplug memory interface 
driven by some kind of daemon, since the pagecache expands to fill all 
available space even when the data is also redundantly cached by the host OS) 
would by via sys_punchole().

Of course UML's physmem file is normally on a tmpfs() mount, where 
madvise(DONTNEED) has special behavior to work like punch anyway.  So it 
looks like special cases to work around this lack can be added ad infinitum 
so there's never any immediate need for the actual generic functionality.

On the other hand, if you're going to support holes at all, having to recreate 
the file to get your hole back is kind of silly.  I personally think the 
ability to create holes in a new file but not create holes in an existing 
file is every bit as strange as being able to extend a file but not truncate 
it.  (See the java 1.1 api for an example of _that_ particular thinko...)

Rob

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

  parent reply	other threads:[~2005-11-21  6:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-10 23:23 Badari Pulavarty
2005-11-10 23:32 ` Andrew Morton
2005-11-10 23:41   ` Badari Pulavarty
2005-11-10 23:55     ` Anton Altaparmakov
2005-11-11  8:25   ` Ingo Oeser
2005-11-11 19:07     ` Christoph Lameter
2005-11-16 12:08     ` Rob Landley
2005-11-16 12:20       ` Andrea Arcangeli
2005-11-13 15:09   ` Pavel Machek
2005-11-16 22:01     ` Badari Pulavarty
2005-11-16 23:37       ` Ric Wheeler
2005-11-21  6:46       ` Rob Landley [this message]
2005-11-18 16:42     ` Ragnar Kjørstad
2005-11-18 16:54       ` Badari Pulavarty
2005-11-11  5:18 ` Arjan van de Ven
2005-11-16 16:05   ` Badari Pulavarty
2005-11-16 16:38     ` Anton Altaparmakov

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=200511210046.45236.rob@landley.net \
    --to=rob@landley.net \
    --cc=akpm@osdl.org \
    --cc=andrea@suse.de \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pavel@suse.cz \
    --cc=pbadari@us.ibm.com \
    /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