From: Michal Hocko <mhocko@kernel.org>
To: miles.chen@mediatek.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
Joe Perches <joe@perches.com>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, wsd_upstream@mediatek.com
Subject: Re: [PATCH v3] mm/page_owner: use kvmalloc instead of kmalloc
Date: Mon, 29 Oct 2018 09:07:08 +0100 [thread overview]
Message-ID: <20181029080708.GA32673@dhcp22.suse.cz> (raw)
In-Reply-To: <1540790176-32339-1-git-send-email-miles.chen@mediatek.com>
On Mon 29-10-18 13:16:16, miles.chen@mediatek.com wrote:
> From: Miles Chen <miles.chen@mediatek.com>
>
> The kbuf used by page owner is allocated by kmalloc(), which means it
> can use only normal memory and there might be a "out of memory"
> issue when we're out of normal memory.
>
> To solve this problem, use kvmalloc() to allocate kbuf
> from normal/highmem. But there is one problem here: kvmalloc()
> does not fallback to vmalloc for sub page allocations. So sub
> page allocation fails due to out of normal memory cannot fallback
> to vmalloc.
>
> Modify kvmalloc() to allow sub page allocations fallback to
> vmalloc when CONFIG_HIGHMEM=y and use kvmalloc() to allocate
> kbuf.
>
> Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation.
>
> Change since v2:
> - improve kvmalloc, allow sub page allocations fallback to
> vmalloc when CONFIG_HIGHMEM=y
Matthew has suggested a much more viable way to go around this. We do
not really want to allow an unbound kernel allocation - even if the
interface is root only.
Besides that, the following doesn't make much sense to me. It simply
makes no sense to use vmalloc for sub page allocation regardless of
HIGHMEM.
> diff --git a/mm/util.c b/mm/util.c
> index 8bf08b5b5760..7b1c59b9bfbf 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -416,10 +416,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
> ret = kmalloc_node(size, kmalloc_flags, node);
>
> /*
> - * It doesn't really make sense to fallback to vmalloc for sub page
> - * requests
> + * It only makes sense to fallback to vmalloc for sub page
> + * requests if we might be able to allocate highmem pages.
> */
> - if (ret || size <= PAGE_SIZE)
> + if (ret || (!IS_ENABLED(CONFIG_HIGHMEM) && size <= PAGE_SIZE))
> return ret;
>
> return __vmalloc_node_flags_caller(size, node, flags,
> --
> 2.18.0
>
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-10-29 8:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 5:16 [PATCH v3] mm/page_owner: use kvmalloc instead of kmalloc miles.chen
2018-10-29 8:07 ` Michal Hocko [this message]
2018-10-29 8:17 ` Michal Hocko
2018-10-30 1:29 ` Miles Chen
2018-10-30 6:06 ` Michal Hocko
2018-10-30 6:55 ` Miles Chen
2018-10-30 8:15 ` Michal Hocko
2018-10-31 8:47 ` Miles Chen
2018-10-31 10:15 ` Michal Hocko
2018-10-31 10:19 ` Miles Chen
2018-10-31 11:41 ` Michal Hocko
2018-11-01 10:00 ` Miles Chen
2018-11-01 10:27 ` Michal Hocko
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=20181029080708.GA32673@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=joe@perches.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=miles.chen@mediatek.com \
--cc=willy@infradead.org \
--cc=wsd_upstream@mediatek.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;
as well as URLs for NNTP newsgroup(s).