On Mon, Mar 16, 2015 at 7:49 PM, Roman Peniaev <[email protected]> wrote: > On Mon, Mar 16, 2015 at 7:28 PM, Gioh Kim <[email protected]> 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 <[email protected]> >>> Cc: Nick Piggin <[email protected]> >>> Cc: Eric Dumazet <[email protected]> >>> Cc: Joonsoo Kim <[email protected]> >>> Cc: David Rientjes <[email protected]> >>> Cc: WANG Chao <[email protected]> >>> Cc: Fabian Frederick <[email protected]> >>> Cc: Christoph Lameter <[email protected]> >>> Cc: Gioh Kim <[email protected]> >>> Cc: Rob Jones <[email protected]> >>> Cc: [email protected] >>> Cc: [email protected] >>> Cc: [email protected] >>> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
