Re: [ATTEND] many topics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

Example usages that I have questions about:

1. Is it permissible to call kmalloc(GFP_TEMPORARY), or is it only
for alloc_pages?  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()?

3. Can I make one GFP_TEMPORARY allocation, and then another one?

4. Should I disable preemption while holding a GFP_TEMPORARY allocation,
or are we OK with a task being preempted?

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

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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux