On Thu 19-01-17 03:05:13, willy@xxxxxxxxxxxxx wrote:
> On Wed, Jan 18, 2017 at 02:32:43PM +0100, Michal Hocko wrote:
> > On Tue 17-01-17 21:49:45, Matthew Wilcox wrote:
> > [...]
> > > 8. Nailing down exactly what GFP_TEMPORARY means
> >
> > It's a hint that the page allocator should group those pages together
> > for better fragmentation avoidance. Have a look at e12ba74d8ff3 ("Group
> > short-lived and reclaimable kernel allocations"). Basically it is
> > something like __GFP_MOVABLE for kernel allocations which cannot go to
> > the movable zones.
>
> Let me rephrase the topic ... Under what conditions should somebody use
> the GFP_TEMPORARY gfp_t?
Most users of slab (kmalloc) do not really have to care. Slab will add
__GFP_RECLAIMABLE to all reclaimable caches automagically AFAIR. The
remaining would have to implement some kind of shrinker to allow the
reclaim.
> Example usages that I have questions about:
>
> 1. Is it permissible to call kmalloc(GFP_TEMPORARY), or is it only
> for alloc_pages?
kmalloc will use it internally as mentioned above. I am not even sure
whether direct using of kmalloc(GFP_TEMPORARY) is ok. I would have to
check the code but I guess it would be just wrong unless you know your
cache is reclaimable.
> I ask because if the slab allocator is unaware of
> GFP_TEMPORARY, then a non-GFP_TEMPORARY allocation may be placed in a
> page allocated with GFP_TEMPORARY and we've just made it meaningless.
>
> 2. Is it permissible to sleep while holding a GFP_TEMPORARY allocation?
> eg, take a mutex, or wait_for_completion()?
Yes, GFP_TEMPORARY has ___GFP_DIRECT_RECLAIM set so this is by
definition sleepable allocation request.
> 3. Can I make one GFP_TEMPORARY allocation, and then another one?
Not sure I understand. WHy would be a problem?
> 4. Should I disable preemption while holding a GFP_TEMPORARY allocation,
> or are we OK with a task being preempted?
no, it can sleep.
> 5. What about something even longer duration like allocating a kiocb?
> That might take an arbitrary length of time to be freed, but eventually
> the command will be timed out (eg 30 seconds for something that ends up
> going through SCSI).
I do not understand. The reclaimability of the object is in hands of the
respective shrinker...
> 6. Or shorter duration like doing a GFP_TEMPORARY allocation, then taking
> a spinlock, which *probably* isn't contended, but you never know.
>
> 7. I can see it includes __GFP_WAIT so it's not suitable for using from
> interrupt context, but interrupt context might be the place which can
> benefit from it the most. Or does GFP_ATOMIC's __GFP_HIGH also allow for
> allocation from the movable zone? Should we have a GFP_TEMPORARY_ATOMIC?
This is where __GFP_RECLAIMABLE should be used as this is the core of
the functionality.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
