From: Michal Hocko <mhocko@kernel.org>
To: Tahsin Erdogan <tahsin@google.com>
Cc: Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Wilson <chris@chris-wilson.co.uk>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Roman Pen <r.peniaev@gmail.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
zijun_hu <zijun_hu@htc.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] percpu: improve allocation success rate for non-GFP_KERNEL callers
Date: Mon, 27 Feb 2017 10:52:59 +0100 [thread overview]
Message-ID: <20170227095258.GG14029@dhcp22.suse.cz> (raw)
In-Reply-To: <20170226043829.14270-1-tahsin@google.com>
On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote:
> When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of
> a failure is higher than GFP_KERNEL case. This is mainly because
> pcpu_alloc() relies on previously allocated reserves and does not make
> an effort to add memory to its pools for non-GFP_KERNEL case.
Who is going to use a different mask?
> This issue is somewhat mitigated by kicking off a background work when
> a memory allocation failure occurs. But this doesn't really help the
> original victim of allocation failure.
>
> This problem affects blkg_lookup_create() callers on machines with a
> lot of cpus.
>
> This patch reduces failure cases by trying to expand the memory pools.
> It passes along gfp flag so it is safe to allocate memory this way.
>
> To make this work, a gfp flag aware vmalloc_gfp() function is added.
> Also, locking around vmap_area_lock has been updated to save/restore
> irq flags. This was needed to avoid a lockdep problem between
> request_queue->queue_lock and vmap_area_lock.
We already have __vmalloc_gfp, why this cannot be used? Also note that
vmalloc dosn't really support arbitrary gfp flags. One have to be really
careful because there are some internal allocations which are hardcoded
GFP_KERNEL. Also this patch doesn't really add any new callers so it is
hard to tell whether what you do actually makes sense and is correct.
--
Michal Hocko
SUSE Labs
--
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:[~2017-02-27 9:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-25 21:00 [PATCH " Tahsin Erdogan
2017-02-25 23:54 ` kbuild test robot
2017-02-26 0:48 ` kbuild test robot
2017-02-26 4:38 ` [PATCH v2 " Tahsin Erdogan
2017-02-27 9:52 ` Michal Hocko [this message]
2017-02-27 13:00 ` Tahsin Erdogan
2017-02-27 15:25 ` Michal Hocko
2017-02-27 17:01 ` Tahsin Erdogan
2017-02-27 17:07 ` Michal Hocko
2017-02-27 17:14 ` Michal Hocko
2017-02-27 19:32 ` Tahsin Erdogan
2017-02-27 19:47 ` Michal Hocko
2017-02-27 19:51 ` Tejun Heo
2017-02-27 20:27 ` Tahsin Erdogan
2017-02-27 20:29 ` Tejun Heo
2017-02-27 20:37 ` Tahsin Erdogan
2017-02-27 20:45 ` Tejun Heo
2017-02-27 21:12 ` Tahsin Erdogan
2017-02-27 21:28 ` Tejun Heo
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=20170227095258.GG14029@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=chris@chris-wilson.co.uk \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=r.peniaev@gmail.com \
--cc=rientjes@google.com \
--cc=tahsin@google.com \
--cc=tj@kernel.org \
--cc=zijun_hu@htc.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox