On Mon, Mar 16, 2015 at 7:28 PM, Gioh Kim [off-list ref] wrote:

2015-03-13 오후 9:12에 Roman Pen 이(가) 쓴 글:

quoted

Hello all.

Recently I came across high fragmentation of vm_map_ram allocator: vmap_block
has free space, but still new blocks continue to appear.  Further investigation
showed that certain mapping/unmapping sequence can exhaust vmalloc space.  On
small 32bit systems that's not a big problem, cause purging will be called soon
on a first allocation failure (alloc_vmap_area), but on 64bit machines, e.g.
x86_64 has 45 bits of vmalloc space, that can be a disaster.

I think the problem you comments is already known so that I wrote comments about it as
"it could consume lots of address space through fragmentation".

Could you tell me about your situation and reason why it should be avoided?

In the first patch of this set I explicitly described the function,
which exhausts
vmalloc space without any chance to be purged: vm_map_ram allocator is
greedy and firstly
tries to occupy newly allocated block, even old blocks contain enough
free space.

This can be easily fixed if we put newly allocated block (which has
enough space to
complete further requests) to the tail of a free list, to give a
chance to old blocks.

Why it should be avoided?  Strange question.  For me it looks like a
bug of an allocator,
which should be fair and should not continuously allocate new blocks
without lazy purging
(seems vmap_lazy_nr and  __purge_vmap_area_lazy were created exactly
for those reasons:
 to avoid infinite allocations)


--
Roman

quoted

Fixing this I also did some tweaks in allocation logic of a new vmap block and
replaced dirty bitmap with min/max dirty range values to make the logic simpler.

I would like to receive comments on the following three patches.

Thanks.

Roman Pen (3):
   mm/vmalloc: fix possible exhaustion of vmalloc space caused by
     vm_map_ram allocator
   mm/vmalloc: occupy newly allocated vmap block just after allocation
   mm/vmalloc: get rid of dirty bitmap inside vmap_block structure

  mm/vmalloc.c | 94 ++++++++++++++++++++++++++++++++++--------------------------
  1 file changed, 54 insertions(+), 40 deletions(-)

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Nick Piggin <redacted>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Joonsoo Kim <redacted>
Cc: David Rientjes <rientjes@google.com>
Cc: WANG Chao <redacted>
Cc: Fabian Frederick <redacted>
Cc: Christoph Lameter <redacted>
Cc: Gioh Kim <redacted>
Cc: Rob Jones <redacted>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org

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