On Mon, Mar 16, 2015 at 7:49 PM, Roman Peniaev <r.peni...@gmail.com> wrote: > On Mon, Mar 16, 2015 at 7:28 PM, Gioh Kim <gioh....@lge.com> 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 <a...@linux-foundation.org> >>> Cc: Nick Piggin <npig...@kernel.dk> >>> Cc: Eric Dumazet <eduma...@google.com> >>> Cc: Joonsoo Kim <iamjoonsoo....@lge.com> >>> Cc: David Rientjes <rient...@google.com> >>> Cc: WANG Chao <chaow...@redhat.com> >>> Cc: Fabian Frederick <f...@skynet.be> >>> Cc: Christoph Lameter <c...@linux.com> >>> Cc: Gioh Kim <gioh....@lge.com> >>> Cc: Rob Jones <rob.jo...@codethink.co.uk> >>> Cc: linux...@kvack.org >>> Cc: linux-kernel@vger.kernel.org >>> Cc: sta...@vger.kernel.org >>> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
