LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Joonsoo Kim <js1304@gmail.com>
To: Roman Pen <r.peniaev@gmail.com>
Cc: Nick Piggin <npiggin@kernel.dk>,
	Zhang Yanfei <zhangyanfei@cn.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	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>, Gioh Kim <gioh.kim@lge.com>,
	Rob Jones <rob.jones@codethink.co.uk>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] mm/vmalloc: get rid of dirty bitmap inside vmap_block structure
Date: Wed, 18 Mar 2015 14:52:03 +0900	[thread overview]
Message-ID: <CAAmzW4MPkFzV0kuQy=nE9nWqFRWCq3S00_DgGiYtPtf2Lzp7_A@mail.gmail.com> (raw)
In-Reply-To: <1426248777-19768-4-git-send-email-r.peniaev@gmail.com>

2015-03-13 21:12 GMT+09:00 Roman Pen <r.peniaev@gmail.com>:
> In original implementation of vm_map_ram made by Nick Piggin there were two
> bitmaps:  alloc_map and dirty_map.  None of them were used as supposed to be:
> finding a suitable free hole for next allocation in block. vm_map_ram allocates
> space sequentially in block and on free call marks pages as dirty, so freed
> space can't be reused anymore.
>
> Actually would be very interesting to know the real meaning of those bitmaps,
> maybe implementation was incomplete, etc.
>
> But long time ago Zhang Yanfei removed alloc_map by these two commits:
>
>   mm/vmalloc.c: remove dead code in vb_alloc
>      3fcd76e8028e0be37b02a2002b4f56755daeda06
>   mm/vmalloc.c: remove alloc_map from vmap_block
>      b8e748b6c32999f221ea4786557b8e7e6c4e4e7a
>
> In current patch I replaced dirty_map with two range variables: dirty min and
> max.  These variables store minimum and maximum position of dirty space in a
> block, since we need only to know the dirty range, not exact position of dirty
> pages.
>
> Why it was made? Several reasons: at first glance it seems that vm_map_ram
> allocator concerns about fragmentation thus it uses bitmaps for finding free
> hole, but it is not true.  To avoid complexity seems it is better to use
> something simple, like min or max range values.  Secondly, code also becomes
> simpler, without iteration over bitmap, just comparing values in min and max
> macros.  Thirdly, bitmap occupies up to 1024 bits (4MB is a max size of a
> block).  Here I replaced the whole bitmap with two longs.
>
> Finally vm_unmap_aliases should be slightly faster and the whole vmap_block
> structure occupies less memory.
>
> Signed-off-by: Roman Pen <r.peniaev@gmail.com>
> Cc: Nick Piggin <npiggin@kernel.dk>
> Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> 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

Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

  reply	other threads:[~2015-03-18  5:52 UTC|newest]

Thread overview: 16+ 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 ` [PATCH 1/3] mm/vmalloc: fix possible exhaustion of vmalloc space caused by vm_map_ram allocator Roman Pen
2015-03-17  4:56   ` Joonsoo Kim
2015-03-17  5:12     ` Roman Peniaev
2015-03-17  7:29       ` Joonsoo Kim
2015-03-17  8:22         ` Roman Peniaev
2015-03-17 21:58           ` Andrew Morton
2015-03-18  5:07             ` 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-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-18  5:52   ` Joonsoo 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:49   ` 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='CAAmzW4MPkFzV0kuQy=nE9nWqFRWCq3S00_DgGiYtPtf2Lzp7_A@mail.gmail.com' \
    --to=js1304@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chaowang@redhat.com \
    --cc=cl@linux.com \
    --cc=edumazet@google.com \
    --cc=fabf@skynet.be \
    --cc=gioh.kim@lge.com \
    --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=zhangyanfei@cn.fujitsu.com \
    --subject='Re: [PATCH 3/3] mm/vmalloc: get rid of dirty bitmap inside vmap_block structure' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).