All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Roman Peniaev <r.peniaev@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Eric Dumazet <edumazet@google.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-mm@kvack.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH 1/3] mm/vmalloc: fix possible exhaustion of vmalloc space caused by vm_map_ram allocator
Date: Tue, 17 Mar 2015 14:58:23 -0700	[thread overview]
Message-ID: <20150317145823.3213cba4dc629c716df0fdd9@linux-foundation.org> (raw)
In-Reply-To: <CACZ9PQUO4cBsTdO37n4UWeHk=26g_WqWo-cVsDCf8E1gkq2Zkg@mail.gmail.com>

On Tue, 17 Mar 2015 17:22:46 +0900 Roman Peniaev <r.peniaev@gmail.com> wrote:

> >> My second patch fixes this problem.
> >> I occupy the block on allocation and avoid jumping to the search loop.
> >
> > I'm not sure that this fixes above case.
> > 'vm_map_ram (3) * 85' means 85 times vm_map_ram() calls.
> >
> > First vm_map_ram(3) caller could get benefit from your second patch.
> > But, second caller and the other callers in each iteration could not
> > get benefit and should iterate whole list to find suitable free block,
> > because this free block is put to the tail of the list. Am I missing
> > something?
> 
> You are missing the fact that we occupy blocks in 2^n.
> So in your example 4 page slots will be occupied (order is 2), not 3.

Could you please

- update the changelogs so they answer the questions which Joonsoo
  Kim and Gioh Kim asked

- write a little in-kernel benchmark to test the scenario which
  Joonsoo described and include the before and after timing results in
  the changelogs

- resend the patchset

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Roman Peniaev <r.peniaev@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Eric Dumazet <edumazet@google.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-mm@kvack.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH 1/3] mm/vmalloc: fix possible exhaustion of vmalloc space caused by vm_map_ram allocator
Date: Tue, 17 Mar 2015 14:58:23 -0700	[thread overview]
Message-ID: <20150317145823.3213cba4dc629c716df0fdd9@linux-foundation.org> (raw)
In-Reply-To: <CACZ9PQUO4cBsTdO37n4UWeHk=26g_WqWo-cVsDCf8E1gkq2Zkg@mail.gmail.com>

On Tue, 17 Mar 2015 17:22:46 +0900 Roman Peniaev <r.peniaev@gmail.com> wrote:

> >> My second patch fixes this problem.
> >> I occupy the block on allocation and avoid jumping to the search loop.
> >
> > I'm not sure that this fixes above case.
> > 'vm_map_ram (3) * 85' means 85 times vm_map_ram() calls.
> >
> > First vm_map_ram(3) caller could get benefit from your second patch.
> > But, second caller and the other callers in each iteration could not
> > get benefit and should iterate whole list to find suitable free block,
> > because this free block is put to the tail of the list. Am I missing
> > something?
> 
> You are missing the fact that we occupy blocks in 2^n.
> So in your example 4 page slots will be occupied (order is 2), not 3.

Could you please

- update the changelogs so they answer the questions which Joonsoo
  Kim and Gioh Kim asked

- write a little in-kernel benchmark to test the scenario which
  Joonsoo described and include the before and after timing results in
  the changelogs

- resend the patchset

Thanks.

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

  reply	other threads:[~2015-03-17 21:58 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 [this message]
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 ` [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: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=20150317145823.3213cba4dc629c716df0fdd9@linux-foundation.org \
    --to=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=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.