On Mon, Mar 16, 2015 at 7:49 PM, Roman Peniaev <r.peniaev@xxxxxxxxx> wrote: > On Mon, Mar 16, 2015 at 7:28 PM, Gioh Kim <gioh.kim@xxxxxxx> wrote: >> >> >> 2015-03-13 오후 9:12에 Roman Pen 이(가) 쓴 글: >>> 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) And if you are talking about your commit 364376383, which adds this comment * If you use this function for less than VMAP_MAX_ALLOC pages, it could be * faster than vmap so it's good. But if you mix long-life and short-life * objects with vm_map_ram(), it could consume lots of address space through * fragmentation (especially on a 32bit machine). You could see failures in * the end. Please use this function for short-lived objects. This is not that case, because if block is pinned, i.e. some pages are still in use, we can't do anything with that. I am talking about blocks, which are completely freed, but dirty. -- Roman > > > -- > Roman > > >> >> >>> >>> 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@xxxxxxxxxxxxxxxxxxxx> >>> Cc: Nick Piggin <npiggin@xxxxxxxxx> >>> Cc: Eric Dumazet <edumazet@xxxxxxxxxx> >>> Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> >>> Cc: David Rientjes <rientjes@xxxxxxxxxx> >>> Cc: WANG Chao <chaowang@xxxxxxxxxx> >>> Cc: Fabian Frederick <fabf@xxxxxxxxx> >>> Cc: Christoph Lameter <cl@xxxxxxxxx> >>> Cc: Gioh Kim <gioh.kim@xxxxxxx> >>> Cc: Rob Jones <rob.jones@xxxxxxxxxxxxxxx> >>> Cc: linux-mm@xxxxxxxxx >>> Cc: linux-kernel@xxxxxxxxxxxxxxx >>> Cc: stable@xxxxxxxxxxxxxxx >>> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href