Re: [ATTEND] many topics

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

 



On 01/25/2017 09:36 PM, Matthew Wilcox wrote:
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.

Sounds right, AFAIK there's no smarts in slab about this.

 - GFP_TEMPORARY allocations may be held on to for a considerable length
   of time; certainly seconds and maybe minutes.

I'd agree.

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

There's no such provision in the current implementation.

   - Other higher-order allocations are more likely to succeed due to
     the segregation of short and long lived allocations from each other.

Right.

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

Before doing things like that, we should evaluate whether the benefits are really worth it. I only know how the mobility grouping and related heuristics work, but haven't measured or seen some results wrt GFP_TEMPORARY. Also are there some large potential users you have in mind? If there's always some constant small amount of temporary allocations in the system, then the benefits should be rather small as that amount will be effectively non-defragmentable in any given point of time. I would expect the most benefit when there are some less frequent but large bursts of temporary allocations concurrently with long-term unmovable allocations that will result in permanently polluting new pageblocks.

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