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