Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1497998

Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency

Path csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From Joel Fernandes <joel.opensrc@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
Date Sun, 09 Oct 2016 21:10:01 +0200
Message-ID <sqrDX-89N-1@gated-at.bofh.it> (permalink)
References <smE6K-10y-13@gated-at.bofh.it> <smEJr-1zc-1@gated-at.bofh.it> <sqdhD-7qZ-1@gated-at.bofh.it> <sqlId-4dC-3@gated-at.bofh.it>
X-Original-To Chris Wilson <chris@chris-wilson.co.uk>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KZzaI0inqm4JvvLAwzfTUb4aTSuml0vrQ+3cWLPVVSo=; b=QAy4ggw+lSVGdmGbXalKG1NZ1puGHrIyHVk70nXMne/hzMVcOz8rVYUJyMP5XRemKh 939Cdj9Hj4nQEmoBVZ4ei4LnlVSCIMHJAyP3NbBDsgIriWSrWU3Y2WRCNfCbnvfVRq7P 2/eWE3lAbosqvqEy2Vwh/rFudLYR1AXQ/20rOnyggcgB8tTRbNYcxuKXayJy25jqNn7W anIAZnzETmEjtIiLpcpCrHzMnq6zu53xq9yJ020JYg1CIwY314F6+BnFVoHhF57cvjIk PE2/Q0SaGmr/WIA+17KY6KlB0o07pttDqR53fkPx/yRws9OUKpMtht3OT7kFgALtxBf2 dLSA==
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KZzaI0inqm4JvvLAwzfTUb4aTSuml0vrQ+3cWLPVVSo=; b=BBbwFC2ZHRFJUzjjTZe3YrS3zI3j2aZKi18Cmjq9JfFUlGr6WHNo0jaOCh+Dnjat42 bTdAWu81VS8RLNzPq2w3UtLA5ORPEExnEH8hiohUXzVhcXK95AP8+G9Ago/x1w3TJbc4 EpxQ1koz7ozNlXcXMsAiFTSXSk17Z3uXoc8cwy2m99dfIWpAR7Kq4glLrpDJqEgJl+mr U0/suGrLwU3gVM4fVsRafSJCb0+FTBr0zpCaY7qMn+8syirMWZrQ8I6N+vUqpexQx2mW t2H2iMeAy9murjk0ajlDooNqgeFEuoaNMUEOjXHXARuGs7FUDhbNMtE3grZz1TKmaGf6 1QBg==
X-Gm-Message-State AA6/9RlIE40o7zfhbI3eavnktD6kD3ebB5+1LdqvTPTSgktGRsvzkIejvQ8RxjLytlfP9cG6gMcKamVu85j6Sw==
X-Received by 10.194.153.199 with SMTP id vi7mr25193487wjb.137.1476039632331; Sun, 09 Oct 2016 12:00:32 -0700 (PDT)
MIME-Version 1.0
Content-Type text/plain; charset=UTF-8
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 75
Organization linux.* mail to news gateway
X-Original-Cc Joel Fernandes <agnel.joel@gmail.com>, Jisheng Zhang <jszhang@marvell.com>, npiggin@kernel.dk, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, rientjes@google.com, Andrew Morton <akpm@linux-foundation.org>, mgorman@techsingularity.net, iamjoonsoo.kim@lge.com, Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>
X-Original-Date Sun, 9 Oct 2016 12:00:31 -0700
X-Original-Message-ID <CAEi0qNnozbib-92NwWpUV=_YiiUHYGzzBuuY8kDZY9gaZm-W7Q@mail.gmail.com>
X-Original-References <20160929073411.3154-1-jszhang@marvell.com> <20160929081818.GE28107@nuc-i3427.alporthouse.com> <CAD=GYpYKL9=uY=Fks2xO6oK3bJ772yo4EiJ1tJkVU9PheSD+Cw@mail.gmail.com> <20161009124242.GA2718@nuc-i3427.alporthouse.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1497998

Show key headers only | View raw


On Sun, Oct 9, 2016 at 5:42 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
[..]
>> > My understanding is that
>> >
>> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> > index 91f44e78c516..3f7c6d6969ac 100644
>> > --- a/mm/vmalloc.c
>> > +++ b/mm/vmalloc.c
>> > @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
>> >  static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> >                                         int sync, int force_flush)
>> >  {
>> > -       static DEFINE_SPINLOCK(purge_lock);
>> >         struct llist_node *valist;
>> >         struct vmap_area *va;
>> >         struct vmap_area *n_va;
>> > @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> >          * should not expect such behaviour. This just simplifies locking for
>> >          * the case that isn't actually used at the moment anyway.
>> >          */
>> > -       if (!sync && !force_flush) {
>> > -               if (!spin_trylock(&purge_lock))
>> > -                       return;
>> > -       } else
>> > -               spin_lock(&purge_lock);
>> > -
>> >         if (sync)
>> >                 purge_fragmented_blocks_allcpus();
>> >
>> > @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> >                         __free_vmap_area(va);
>> >                 spin_unlock(&vmap_area_lock);
>> >         }
>> > -       spin_unlock(&purge_lock);
>> >  }
>> >
>> [..]
>> > should now be safe. That should significantly reduce the preempt-disabled
>> > section, I think.
>>
>> I believe that the purge_lock is supposed to prevent concurrent purges
>> from happening.
>>
>> For the case where if you have another concurrent overflow happen in
>> alloc_vmap_area() between the spin_unlock and purge :
>>
>> spin_unlock(&vmap_area_lock);
>> if (!purged)
>>    purge_vmap_area_lazy();
>>
>> Then the 2 purges would happen at the same time and could subtract
>> vmap_lazy_nr twice.
>
> That itself is not the problem, as each instance of
> __purge_vmap_area_lazy() operates on its own freelist, and so there will
> be no double accounting.
>
> However, removing the lock removes the serialisation which does mean
> that alloc_vmap_area() will not block on another thread conducting the
> purge, and so it will try to reallocate before that is complete and the
> free area made available. It also means that we are doing the
> atomic_sub(vmap_lazy_nr) too early.
>
> That supports making the outer lock a mutex as you suggested. But I think
> cond_resched_lock() is better for the vmap_area_lock (just because it
> turns out to be an expensive loop and we may want the reschedule).
> -Chris

Ok. So I'll submit a patch with mutex for purge_lock and use
cond_resched_lock for the vmap_area_lock as you suggested. I'll also
drop the lazy_max_pages to 8MB as Andi suggested to reduce the lock
hold time. Let me know if you have any objections.

Thanks,
Joel

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency Jisheng Zhang <jszhang@marvell.com> - 2016-09-29 09:40 +0200
  Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to  reduce latency Chris Wilson <chris@chris-wilson.co.uk> - 2016-09-29 10:20 +0200
    Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to  reduce latency Jisheng Zhang <jszhang@marvell.com> - 2016-09-29 10:40 +0200
      Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to  reduce latency Chris Wilson <chris@chris-wilson.co.uk> - 2016-09-29 13:10 +0200
        Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to  reduce latency Jisheng Zhang <jszhang@marvell.com> - 2016-09-29 13:30 +0200
    Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency Joel Fernandes <agnel.joel@gmail.com> - 2016-10-09 05:50 +0200
      Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to  reduce latency Chris Wilson <chris@chris-wilson.co.uk> - 2016-10-09 14:50 +0200
        Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency Joel Fernandes <joel.opensrc@gmail.com> - 2016-10-09 21:10 +0200
          Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to  reduce latency Chris Wilson <chris@chris-wilson.co.uk> - 2016-10-09 21:30 +0200
            Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency Joel Fernandes <agnel.joel@gmail.com> - 2016-10-11 07:10 +0200
              Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency Joel Fernandes <agnel.joel@gmail.com> - 2016-10-11 07:40 +0200

csiph-web