Re: [ATTEND] many topics

[Michal Hocko <mhocko@kernel.org>]

On Thu 19-01-17 03:52:43, willy@bombadil.infradead.org wrote:
> On Thu, Jan 19, 2017 at 12:33:17PM +0100, Michal Hocko wrote:
> > On Thu 19-01-17 03:05:13, willy@infradead.org wrote:
> > > 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.
> 
> I seem to be not making myself clear.  Picture me writing a device driver.
> When should I use GFP_TEMPORARY?

I guess the original intention was to use this flag for allocations
which will be either freed shortly or they are reclaimable.
 
> > > 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.
> 
> You're not using words that have any meaning to a device driver writer.
> Here's my code:
> 
> int foo_ioctl(..)
> {
> 	struct foo *foo = kmalloc(sizeof(*foo), GFP_TEMPORARY);
> }
> 
> Does this work?  If not, should it?  Or should slab be checking for
> this and calling WARN()?

I would have to check the code but I believe that this shouldn't be
harmful other than increase the fragmentation.

> > > 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.
> 
> Again, we're talking past each other.  Can foo_ioctl() sleep before
> releasing its GFP_TEMPORARY allocation, or will that make the memory
> allocator unhappy?

I do not think it would make the allocator unhappy as long as the sleep
is not for ever...

> > > 3. Can I make one GFP_TEMPORARY allocation, and then another one?
> > 
> > Not sure I understand. WHy would be a problem?
> 
> As you say above, GFP_TEMPORARY may sleep, so this is a variation on the "can I sleep while holding a GFP_TEMPORARY allocation" question.
> 
> > > 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...
> 
> There is no shrinker here.  This is about the object being "temporary",
> for some value of temporary.  I want to nail down what the MM is willing
> to tolerate in terms of length of time an object is allocated for.

>From my understanding MM will use the information for optimizing objects
placing and the longer the user will use that memory the worse this
optimization works. I do not think the (ab)use would be fatal...
 
> > > 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.
> 
> This response also doesn't make sense to me.

I meant to say that such an allocation can use __GFP_RECLAIMABLE | __GFP_NOWAIT.


-- 
Michal Hocko
SUSE Labs

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