From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: kosaki.motohiro@jp.fujitsu.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: [PATCH v5] add MAP_UNLOCKED mmap flag
Date: Thu, 14 Jan 2010 16:02:42 +0900 (JST) [thread overview]
Message-ID: <20100114155229.6735.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <20100114065008.GC18808@redhat.com>
> On Thu, Jan 14, 2010 at 09:31:03AM +0900, KOSAKI Motohiro wrote:
> > > If application does mlockall(MCL_FUTURE) it is no longer possible to mmap
> > > file bigger than main memory or allocate big area of anonymous memory
> > > in a thread safe manner. Sometimes it is desirable to lock everything
> > > related to program execution into memory, but still be able to mmap
> > > big file or allocate huge amount of memory and allow OS to swap them on
> > > demand. MAP_UNLOCKED allows to do that.
> > >
> > > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > > ---
> > >
> > > I get reports that people find this useful, so resending.
> >
> > This description is still wrong. It doesn't describe why this patch is useful.
> >
> I think the text above describes the feature it adds and its use
> case quite well. Can you elaborate what is missing in your opinion,
> or suggest alternative text please?
My point is, introducing mmap new flags need strong and clearly use-case.
All patch should have good benefit/cost balance. the code can describe the cost,
but the benefit can be only explained by the patch description.
I don't think this poor description explained bit benefit rather than cost.
you should explain why this patch is useful and not just pretty toy.
--
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>
next prev parent reply other threads:[~2010-01-14 7:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-13 9:31 Gleb Natapov
2010-01-13 14:36 ` Américo Wang
2010-01-13 17:31 ` Chris Wright
2010-01-14 0:31 ` KOSAKI Motohiro
2010-01-14 6:50 ` Gleb Natapov
2010-01-14 7:02 ` KOSAKI Motohiro [this message]
2010-01-14 7:22 ` Gleb Natapov
2010-01-14 7:30 ` KOSAKI Motohiro
2010-01-14 8:01 ` Gleb Natapov
2010-01-14 8:17 ` KOSAKI Motohiro
2010-01-14 10:22 ` Gleb Natapov
2010-01-14 19:30 ` Andrew C. Morrow
2010-01-18 3:23 ` KOSAKI Motohiro
2010-01-18 13:40 ` Gleb Natapov
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=20100114155229.6735.A69D9226@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=gleb@redhat.com \
--cc=linux-api@vger.kernel.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