From: NeilBrown <neilb@suse.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Michal Hocko <mhocko@kernel.org>,
willy@bombadil.infradead.org, willy@infradead.org,
lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [ATTEND] many topics
Date: Sun, 22 Jan 2017 15:45:01 +1100 [thread overview]
Message-ID: <87ziijem9e.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20170121131644.zupuk44p5jyzu5c5@thunk.org>
[-- Attachment #1: Type: text/plain, Size: 3889 bytes --]
On Sun, Jan 22 2017, Theodore Ts'o wrote:
> On Sat, Jan 21, 2017 at 11:11:41AM +1100, NeilBrown wrote:
>> What are the benefits of GFP_TEMPORARY? Presumably it doesn't guarantee
>> success any more than GFP_KERNEL does, but maybe it is slightly less
>> likely to fail, and somewhat less likely to block for a long time?? But
>> without some sort of promise, I wonder why anyone would use the
>> flag. Is there a promise? Or is it just "you can be nice to the MM
>> layer by setting this flag sometimes". ???
>
> My understanding is that the idea is to allow short-term use cases not
> to be mixed with long-term use cases --- in the Java world, to declare
> that a particular object will never be promoted from the "nursury"
> arena to the "tenured" arena, so that we don't end up with a situation
> where a page is used 90% for temporary objects, and 10% for a tenured
> object, such that later on we have a page which is 90% unused.
>
> Many of the existing users may in fact be for things like a temporary
> bounce buffer for I/O, where declaring this to the mm system could
> lead to less fragmented pages, but which would violate your proposed
> contract:
>
>> GFP_TEMPORARY should be used when the memory allocated will either be
>> freed, or will be placed in a reclaimable cache, before the process
>> which allocated it enters an TASK_INTERRUPTIBLE sleep or returns to
>> user-space. It allows access to memory which is usually reserved for
>> XXX and so can be expected to succeed more quickly during times of
>> high memory pressure.
>
> I think what you are suggested is something very different, where you
> are thinking that for *very* short-term usage perhaps we could have a
> pool of memory, perhaps the same as the GFP_ATOMIC memory, or at least
> similar in mechanism, where such usage could be handy.
>
> Is there enough use cases where this would be useful? In the local
> disk backed file system world, I doubt it. But maybe in the (for
> example) NFS world, such a use would in fact be common enough that it
> would be useful.
>
> I'd suggest doing this though as a new category, perhaps
> GFP_REALLY_SHORT_TERM, or GFP_MAYFLY for short. :-)
I'm not suggesting this particular contract is necessarily a good thing
to have. I just suggested it as a possible definition of
"GFP_TEMPORARY".
If you are correct, then I was clearly wrong - which nicely serves to
demonstrate that a clear definition is needed.
You have used terms like "nursery" and "tenured" which don't really help
without definitions of those terms.
How about
GFP_TEMPORARY should be used when the memory allocated will either be
freed, or will be placed in a reclaimable cache, after some sequence
of events which is time-limited. i.e. there must be no indefinite
wait on the path from allocation to freeing-or-caching.
The memory will typically be allocated from a region dedicated to
GFP_TEMPORARY allocations, thus ensuring that this region does not
become fragmented. Consequently, the delay imposed on GFP_TEMPORARY
allocations is likely to be less than for non-TEMPORARY allocations
when memory pressure is high.
??
I think that for this definition to work, we would need to make it "a
movable cache", meaning that any item can be either freed or
re-allocated (presumably to a "tenured" location). I don't think we
currently have that concept for slabs do we? That implies that this
flag would only apply to whole-page allocations (which was part of the
original question). We could presumably add movability to
slab-shrinkers if these seemed like a good idea.
I think that it would also make sense to require that the path from
allocation to freeing (or caching) of GFP_TEMPORARY allocation must not
wait for a non-TEMPORARY allocation, as that becomes an indefinite wait.
Is that any closer to your understanding?
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-01-22 4:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 5:49 [ATTEND] many topics Matthew Wilcox
2017-01-18 10:13 ` [Lsf-pc] " Jan Kara
2017-01-18 11:26 ` willy
2017-01-18 13:32 ` Michal Hocko
2017-01-19 11:05 ` willy
2017-01-19 11:33 ` Michal Hocko
2017-01-19 11:52 ` willy
2017-01-19 12:11 ` Michal Hocko
2017-01-21 0:11 ` NeilBrown
2017-01-21 13:16 ` Theodore Ts'o
2017-01-22 4:45 ` NeilBrown [this message]
2017-01-23 6:05 ` Matthew Wilcox
2017-01-23 6:30 ` NeilBrown
2017-01-23 6:35 ` Matthew Wilcox
2017-01-23 17:09 ` Theodore Ts'o
2017-01-23 19:34 ` NeilBrown
2017-01-25 14:36 ` Vlastimil Babka
2017-01-25 20:36 ` Matthew Wilcox
2017-01-25 21:15 ` Vlastimil Babka
2017-01-25 23:19 ` NeilBrown
2017-01-26 8:56 ` Michal Hocko
2017-01-26 21:20 ` NeilBrown
2017-01-27 13:12 ` Michal Hocko
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=87ziijem9e.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@kernel.org \
--cc=tytso@mit.edu \
--cc=willy@bombadil.infradead.org \
--cc=willy@infradead.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).