On Thu, Jan 19, 2017 at 12:33:17PM +0100, Michal Hocko wrote:
> On Thu 19-01-17 03:05:13, willy@xxxxxxxxxxxxx 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?
> > 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 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?
> > 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.
> > 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.
--
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
