From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753430AbbCPK2g (ORCPT ); Mon, 16 Mar 2015 06:28:36 -0400 Received: from LGEMRELSE7Q.lge.com ([156.147.1.151]:40763 "EHLO lgemrelse7q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753100AbbCPK2c (ORCPT ); Mon, 16 Mar 2015 06:28:32 -0400 X-Original-SENDERIP: 10.178.37.108 X-Original-MAILFROM: gioh.kim@lge.com Message-ID: <5506B04D.1070506@lge.com> Date: Mon, 16 Mar 2015 19:28:29 +0900 From: Gioh Kim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Roman Pen CC: Andrew Morton , Nick Piggin , Eric Dumazet , Joonsoo Kim , David Rientjes , WANG Chao , Fabian Frederick , Christoph Lameter , Rob Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 0/3] [RFC] mm/vmalloc: fix possible exhaustion of vmalloc space References: <1426248777-19768-1-git-send-email-r.peniaev@gmail.com> In-Reply-To: <1426248777-19768-1-git-send-email-r.peniaev@gmail.com> Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Cc: Nick Piggin > Cc: Eric Dumazet > Cc: Joonsoo Kim > Cc: David Rientjes > Cc: WANG Chao > Cc: Fabian Frederick > Cc: Christoph Lameter > Cc: Gioh Kim > Cc: Rob Jones > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > Cc: stable@vger.kernel.org >