All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
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  9:04 UTC|newest]

Thread overview: 129+ 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 ` Michal Hocko
2017-01-12 15:37 ` [PATCH 1/6] mm: introduce kv[mz]alloc helpers Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-16  4:34   ` John Hubbard
2017-01-16  4:34     ` John Hubbard
2017-01-16  8:47     ` Michal Hocko
2017-01-16  8:47       ` Michal Hocko
2017-01-16 19:09       ` John Hubbard
2017-01-16 19:09         ` John Hubbard
2017-01-16 19:40         ` Michal Hocko
2017-01-16 19:40           ` Michal Hocko
2017-01-16 21:15           ` John Hubbard
2017-01-16 21:15             ` John Hubbard
2017-01-16 21:48             ` Michal Hocko
2017-01-16 21:48               ` Michal Hocko
2017-01-16 21:57               ` John Hubbard
2017-01-16 21:57                 ` John Hubbard
2017-01-17  7:51                 ` Michal Hocko
2017-01-17  7:51                   ` Michal Hocko
2017-01-18  5:59                   ` John Hubbard
2017-01-18  5:59                     ` John Hubbard
2017-01-18  8:21                     ` Michal Hocko
2017-01-18  8:21                       ` Michal Hocko
2017-01-19  8:37                       ` John Hubbard
2017-01-19  8:37                         ` John Hubbard
2017-01-19  8:45                         ` Michal Hocko
2017-01-19  8:45                           ` Michal Hocko
2017-01-19  9:09                           ` John Hubbard
2017-01-19  9:09                             ` John Hubbard
2017-01-19  9:56                             ` Michal Hocko
2017-01-19  9:56                               ` Michal Hocko
2017-01-19 21:28                               ` John Hubbard
2017-01-19 21:28                                 ` John Hubbard
2017-01-26 12:09   ` Michal Hocko
2017-01-26 12:09     ` Michal Hocko
2017-01-30  8:42     ` Vlastimil Babka
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 15:37   ` Michal Hocko
2017-01-12 16:12   ` Michael S. Tsirkin
2017-01-12 16:12     ` Michael S. Tsirkin
2017-01-14  2:42   ` Tetsuo Handa
2017-01-14  2:42     ` Tetsuo Handa
2017-01-14  8:45     ` Michal Hocko
2017-01-14  8:45       ` Michal Hocko
2017-01-24 15:40   ` Michael S. Tsirkin
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   ` Michal Hocko
2017-01-12 15:37 ` [PATCH 4/6] ila: " Michal Hocko
2017-01-12 15:37   ` 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:37   ` Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-12 15:57   ` David Sterba
2017-01-12 15:57     ` David Sterba
2017-01-12 15:57     ` David Sterba
2017-01-12 16:05   ` Christian Borntraeger
2017-01-12 16:05     ` Christian Borntraeger
2017-01-12 16:05     ` Christian Borntraeger
2017-01-12 16:54   ` Ilya Dryomov
2017-01-12 16:54     ` Ilya Dryomov
2017-01-12 16:54     ` Ilya Dryomov
2017-01-12 17:18     ` Michal Hocko
2017-01-12 17:18       ` Michal Hocko
2017-01-12 17:18       ` Michal Hocko
2017-01-12 17:00   ` Dan Williams
2017-01-12 17:00     ` Dan Williams
2017-01-12 17:00     ` Dan Williams
2017-01-12 17:26   ` Kees Cook
2017-01-12 17:26     ` Kees Cook
2017-01-12 17:26     ` Kees Cook
2017-01-12 17:37     ` Michal Hocko
2017-01-12 17:37       ` Michal Hocko
2017-01-12 17:37       ` Michal Hocko
2017-01-20 13:41       ` Vlastimil Babka
2017-01-20 13:41         ` Vlastimil Babka
2017-01-20 13:41         ` Vlastimil Babka
2017-01-24 15:00         ` Michal Hocko
2017-01-24 15:00           ` Michal Hocko
2017-01-24 15:00           ` Michal Hocko
2017-01-25 11:15           ` Vlastimil Babka
2017-01-25 11:15             ` Vlastimil Babka
2017-01-25 11:15             ` Vlastimil Babka
2017-01-25 13:09             ` Michal Hocko
2017-01-25 13:09               ` Michal Hocko
2017-01-25 13:09               ` Michal Hocko
2017-01-25 13:40               ` Ilya Dryomov
2017-01-25 13:40                 ` Ilya Dryomov
2017-01-25 13:40                 ` Ilya Dryomov
2017-01-12 17:29   ` Michal Hocko
2017-01-12 17:29     ` Michal Hocko
2017-01-12 17:29     ` Michal Hocko
2017-01-14  3:01     ` Tetsuo Handa
2017-01-14  3:01       ` Tetsuo Handa
2017-01-14  8:49       ` Michal Hocko [this message]
2017-01-14  8:49         ` Michal Hocko
2017-01-12 20:14   ` Boris Ostrovsky
2017-01-12 20:14     ` Boris Ostrovsky
2017-01-12 20:14     ` Boris Ostrovsky
2017-01-13  1:11   ` Dilger, Andreas
2017-01-13  1:11     ` Dilger, Andreas
2017-01-13  1:11     ` Dilger, Andreas
2017-01-14 10:56   ` Leon Romanovsky
2017-01-14 10:56     ` Leon Romanovsky
2017-01-16  7:33     ` Michal Hocko
2017-01-16  7:33       ` Michal Hocko
2017-01-16  7:33       ` Michal Hocko
2017-01-16  8:28       ` Leon Romanovsky
2017-01-16  8:28         ` Leon Romanovsky
2017-01-16  8:18   ` Tariq Toukan
2017-01-16  8:18     ` Tariq Toukan
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-12 15:37   ` Michal Hocko
2017-01-12 15:37   ` Michal Hocko
2017-01-24 15:17 ` [PATCH 0/6 v3] kvmalloc Michal Hocko
2017-01-24 15:17   ` Michal Hocko
2017-01-24 16:00   ` Eric Dumazet
2017-01-24 16:00     ` Eric Dumazet
2017-01-25 13:10     ` Michal Hocko
2017-01-25 13:10       ` Michal Hocko
2017-01-24 19:17   ` Alexei Starovoitov
2017-01-24 19:17     ` Alexei Starovoitov
2017-01-25 13:10     ` Michal Hocko
2017-01-25 13:10       ` Michal Hocko
2017-01-25 13:21       ` 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 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.