linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
Date: Sat, 14 Jan 2017 09:49:13 +0100	[thread overview]
Message-ID: <20170114084912.GB9962@dhcp22.suse.cz> (raw)
In-Reply-To: <c0b2f24d-a5e1-5ac7-ccba-347e0f17fd62@I-love.SAKURA.ne.jp>

On Sat 14-01-17 12:01:50, Tetsuo Handa wrote:
> On 2017/01/13 2:29, Michal Hocko wrote:
> > Ilya has noticed that I've screwed up some k[zc]alloc conversions and
> > didn't use the kvzalloc. This is an updated patch with some acks
> > collected on the way
> > ---
> > From a7b89c6d0a3c685045e37740c8f97b065f37e0a4 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mhocko@suse.com>
> > Date: Wed, 4 Jan 2017 13:30:32 +0100
> > Subject: [PATCH] treewide: use kv[mz]alloc* rather than opencoded variants
> > 
> > There are many code paths opencoding kvmalloc. Let's use the helper
> > instead. The main difference to kvmalloc is that those users are usually
> > not considering all the aspects of the memory allocator. E.g. allocation
> > requests < 64kB are basically never failing and invoke OOM killer to
> 
> Isn't this "requests <= 32kB" because allocation requests for 33kB will be
> rounded up to 64kB?

Yes

> Same for "smaller than 64kB" in PATCH 6/6. But strictly speaking, isn't
> it bogus to refer actual size because PAGE_SIZE is not always 4096?

This is just an example and I didn't want to pull
PAGE_ALLOC_COSTLY_ORDER here. So I've instead fixed the wording to:
"
E.g. allocation requests <= 32kB (with 4kB pages) are basically never
failing and invoke OOM killer to satisfy the allocation.
"
-- 
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>

  reply	other threads:[~2017-01-14  8:49 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-12 15:37 [PATCH 0/6 v3] kvmalloc Michal Hocko
2017-01-12 15:37 ` [PATCH 1/6] mm: introduce kv[mz]alloc helpers Michal Hocko
2017-01-16  4:34   ` John Hubbard
2017-01-16  8:47     ` Michal Hocko
2017-01-16 19:09       ` John Hubbard
2017-01-16 19:40         ` Michal Hocko
2017-01-16 21:15           ` John Hubbard
2017-01-16 21:48             ` Michal Hocko
2017-01-16 21:57               ` John Hubbard
2017-01-17  7:51                 ` Michal Hocko
2017-01-18  5:59                   ` John Hubbard
2017-01-18  8:21                     ` Michal Hocko
2017-01-19  8:37                       ` John Hubbard
2017-01-19  8:45                         ` Michal Hocko
2017-01-19  9:09                           ` John Hubbard
2017-01-19  9:56                             ` Michal Hocko
2017-01-19 21:28                               ` John Hubbard
2017-01-26 12:09   ` Michal Hocko
2017-01-30  8:42     ` Vlastimil Babka
2017-01-12 15:37 ` [PATCH 2/6] mm: support __GFP_REPEAT in kvmalloc_node for >=64kB Michal Hocko
2017-01-12 16:12   ` Michael S. Tsirkin
2017-01-14  2:42   ` Tetsuo Handa
2017-01-14  8:45     ` Michal Hocko
2017-01-24 15:40   ` Michael S. Tsirkin
2017-01-12 15:37 ` [PATCH 3/6] rhashtable: simplify a strange allocation pattern Michal Hocko
2017-01-12 15:37 ` [PATCH 4/6] ila: " Michal Hocko
2017-01-12 15:37 ` [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants Michal Hocko
2017-01-12 15:57   ` David Sterba
2017-01-12 16:05   ` Christian Borntraeger
2017-01-12 16:54   ` Ilya Dryomov
2017-01-12 17:18     ` Michal Hocko
2017-01-12 17:00   ` Dan Williams
2017-01-12 17:26   ` Kees Cook
2017-01-12 17:37     ` Michal Hocko
2017-01-20 13:41       ` Vlastimil Babka
2017-01-24 15:00         ` Michal Hocko
2017-01-25 11:15           ` Vlastimil Babka
2017-01-25 13:09             ` Michal Hocko
2017-01-25 13:40               ` Ilya Dryomov
2017-01-12 17:29   ` Michal Hocko
2017-01-14  3:01     ` Tetsuo Handa
2017-01-14  8:49       ` Michal Hocko [this message]
2017-01-12 20:14   ` Boris Ostrovsky
2017-01-13  1:11   ` Dilger, Andreas
2017-01-14 10:56   ` Leon Romanovsky
2017-01-16  7:33     ` Michal Hocko
2017-01-16  8:28       ` Leon Romanovsky
2017-01-16  8:18   ` Tariq Toukan
2017-01-12 15:37 ` [RFC PATCH 6/6] net: use kvmalloc with __GFP_REPEAT rather than open coded variant Michal Hocko
2017-01-24 15:17 ` [PATCH 0/6 v3] kvmalloc Michal Hocko
2017-01-24 16:00   ` Eric Dumazet
2017-01-25 13:10     ` Michal Hocko
2017-01-24 19:17   ` Alexei Starovoitov
2017-01-25 13:10     ` Michal Hocko
2017-01-25 13:21       ` 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=20170114084912.GB9962@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    /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).