From: Gioh Kim <gioh.kim@lge.com>
To: Roman Pen <r.peniaev@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@kernel.dk>,
Eric Dumazet <edumazet@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
WANG Chao <chaowang@redhat.com>,
Fabian Frederick <fabf@skynet.be>,
Christoph Lameter <cl@linux.com>,
Rob Jones <rob.jones@codethink.co.uk>,
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
Date: Mon, 16 Mar 2015 19:28:29 +0900 [thread overview]
Message-ID: <5506B04D.1070506@lge.com> (raw)
In-Reply-To: <1426248777-19768-1-git-send-email-r.peniaev@gmail.com>
2015-03-13 ?AEA 9:12?! Roman Pen AI(?!) 3/4 ' +-U:
> 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 <akpm@linux-foundation.org>
> Cc: Nick Piggin <npiggin@kernel.dk>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: WANG Chao <chaowang@redhat.com>
> Cc: Fabian Frederick <fabf@skynet.be>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Gioh Kim <gioh.kim@lge.com>
> Cc: Rob Jones <rob.jones@codethink.co.uk>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Cc: stable@vger.kernel.org
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Gioh Kim <gioh.kim@lge.com>
To: Roman Pen <r.peniaev@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@kernel.dk>,
Eric Dumazet <edumazet@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
WANG Chao <chaowang@redhat.com>,
Fabian Frederick <fabf@skynet.be>,
Christoph Lameter <cl@linux.com>,
Rob Jones <rob.jones@codethink.co.uk>,
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
Date: Mon, 16 Mar 2015 19:28:29 +0900 [thread overview]
Message-ID: <5506B04D.1070506@lge.com> (raw)
In-Reply-To: <1426248777-19768-1-git-send-email-r.peniaev@gmail.com>
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 <akpm@linux-foundation.org>
> Cc: Nick Piggin <npiggin@kernel.dk>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: WANG Chao <chaowang@redhat.com>
> Cc: Fabian Frederick <fabf@skynet.be>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Gioh Kim <gioh.kim@lge.com>
> Cc: Rob Jones <rob.jones@codethink.co.uk>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Cc: stable@vger.kernel.org
>
WARNING: multiple messages have this Message-ID (diff)
From: Gioh Kim <gioh.kim@lge.com>
To: Roman Pen <r.peniaev@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@kernel.dk>,
Eric Dumazet <edumazet@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
WANG Chao <chaowang@redhat.com>,
Fabian Frederick <fabf@skynet.be>,
Christoph Lameter <cl@linux.com>,
Rob Jones <rob.jones@codethink.co.uk>,
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
Date: Mon, 16 Mar 2015 19:28:29 +0900 [thread overview]
Message-ID: <5506B04D.1070506@lge.com> (raw)
In-Reply-To: <1426248777-19768-1-git-send-email-r.peniaev@gmail.com>
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 <akpm@linux-foundation.org>
> Cc: Nick Piggin <npiggin@kernel.dk>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: WANG Chao <chaowang@redhat.com>
> Cc: Fabian Frederick <fabf@skynet.be>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Gioh Kim <gioh.kim@lge.com>
> Cc: Rob Jones <rob.jones@codethink.co.uk>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Cc: stable@vger.kernel.org
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-03-16 10:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 12:12 [PATCH 0/3] [RFC] mm/vmalloc: fix possible exhaustion of vmalloc space Roman Pen
2015-03-13 12:12 ` Roman Pen
2015-03-13 12:12 ` Roman Pen
2015-03-13 12:12 ` [PATCH 1/3] mm/vmalloc: fix possible exhaustion of vmalloc space caused by vm_map_ram allocator Roman Pen
2015-03-13 12:12 ` Roman Pen
2015-03-13 12:12 ` Roman Pen
2015-03-17 4:56 ` Joonsoo Kim
2015-03-17 4:56 ` Joonsoo Kim
2015-03-17 5:12 ` Roman Peniaev
2015-03-17 5:12 ` Roman Peniaev
2015-03-17 7:29 ` Joonsoo Kim
2015-03-17 7:29 ` Joonsoo Kim
2015-03-17 8:22 ` Roman Peniaev
2015-03-17 8:22 ` Roman Peniaev
2015-03-17 21:58 ` Andrew Morton
2015-03-17 21:58 ` Andrew Morton
2015-03-18 5:07 ` Joonsoo Kim
2015-03-18 5:07 ` Joonsoo Kim
2015-03-18 5:05 ` Joonsoo Kim
2015-03-18 5:05 ` Joonsoo Kim
2015-03-13 12:12 ` [PATCH 2/3] mm/vmalloc: occupy newly allocated vmap block just after allocation Roman Pen
2015-03-13 12:12 ` Roman Pen
2015-03-18 5:51 ` Joonsoo Kim
2015-03-18 5:51 ` Joonsoo Kim
2015-03-13 12:12 ` [PATCH 3/3] mm/vmalloc: get rid of dirty bitmap inside vmap_block structure Roman Pen
2015-03-13 12:12 ` Roman Pen
2015-03-18 5:52 ` Joonsoo Kim
2015-03-18 5:52 ` Joonsoo Kim
2015-03-16 10:28 ` Gioh Kim [this message]
2015-03-16 10:28 ` [PATCH 0/3] [RFC] mm/vmalloc: fix possible exhaustion of vmalloc space Gioh Kim
2015-03-16 10:28 ` Gioh Kim
2015-03-16 10:49 ` Roman Peniaev
2015-03-16 10:49 ` Roman Peniaev
2015-03-16 10:57 ` Roman Peniaev
2015-03-16 10:57 ` Roman Peniaev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5506B04D.1070506@lge.com \
--to=gioh.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=chaowang@redhat.com \
--cc=cl@linux.com \
--cc=edumazet@google.com \
--cc=fabf@skynet.be \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@kernel.dk \
--cc=r.peniaev@gmail.com \
--cc=rientjes@google.com \
--cc=rob.jones@codethink.co.uk \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.