From: Matthew Wilcox <willy@infradead.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: NeilBrown <neilb@suse.com>, Theodore Ts'o <tytso@mit.edu>,
Michal Hocko <mhocko@kernel.org>,
lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [ATTEND] many topics
Date: Wed, 25 Jan 2017 12:36:17 -0800 [thread overview]
Message-ID: <20170125203617.GB970@bombadil.infradead.org> (raw)
In-Reply-To: <58357cf1-65fc-b637-de8e-6cf9c9d91882@suse.cz>
On Wed, Jan 25, 2017 at 03:36:15PM +0100, Vlastimil Babka wrote:
> On 01/23/2017 08:34 PM, NeilBrown wrote:
> > Because "TEMPORARY" implies a limit to the amount of time, and sleeping
> > is the thing that causes a process to take a large amount of time. It
> > seems like an obvious connection to me.
>
> There's no simple connection to time, it depends on the larger picture -
> what's the state of the allocator and what other allocations/free's are
> happening around this one. Perhaps let me try to explain what the flag does
> and what benefits are expected.
The explanations of what GFP_TEMPORARY /does/ keep getting better and
better. And thank you for that, it really is interesting. But what
we're asking for is guidelines for the user of this interface; what is
the contract between the caller and the MM system?
So far, I think we've answered a few questions:
- Using GFP_TEMPORARY in calls to kmalloc() is not currently supported
because slab will happily allocate non-TEMPORARY allocations from the
same page.
- GFP_TEMPORARY allocations may be held on to for a considerable length
of time; certainly seconds and maybe minutes.
- The advantage of marking one's allocation as TEMPORARY is twofold:
- This allocation is more likely to succeed due to being allowed to
access more memory.
- Other higher-order allocations are more likely to succeed due to
the segregation of short and long lived allocations from each other.
I'd like to see us add a tmalloc() / tmalloc_atomic() / tfree() API
for allocating temporary memory, then hook that up to SLAB as a way to
allocate small amounts of memory (... although maybe we shouldn't try
too hard to allocate multiple objects from a single page if they're all
temporary ...)
In any case, we need to ensure that GFP_TEMPORARY is not accepted by
slab ... that's not as straightforward as adding __GFP_RECLAIMABLE to
GFP_SLAB_BUG_MASK because SLAB_RECLAIMABLE slabs will reasonable add
__GFP_RECLAIMABLE before the check. So a good place to check it is ...
kmalloc_slab()? That hits all three slab allocators.
--
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:[~2017-01-25 20:36 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
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 [this message]
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=20170125203617.GB970@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@kernel.org \
--cc=neilb@suse.com \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
/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).