From: Michal Hocko <mhocko@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-mm@kvack.org, virtualization@lists.linux-foundation.org
Subject: GFP_REPEAT usage in vhost_net_open resp. vhost_vsock_dev_open
Date: Wed, 4 Jan 2017 16:08:00 +0100 [thread overview]
Message-ID: <20170104150800.GO25453@dhcp22.suse.cz> (raw)
Hi Michael,
I am currently cleaning up opencoded kmalloc with vmalloc fallback users
[1] and my current kvmalloc_node helper doesn't support GFP_REPEAT
because there are no users which would need it. At least that's what I
thought until I've encountered vhost_vsock_dev_open resp.
vhost_vsock_dev_open which are trying to use GFP_REPEAT for kmalloc.
23cc5a991c7a ("vhost-net: extend device allocation to vmalloc") explains
the motivation as follows:
"
As vmalloc() adds overhead on a critical network path, add __GFP_REPEAT
to kzalloc() flags to do this fallback only when really needed.
"
I am wondering whether vmalloc adds more overhead than GFP_REPEAT which
can get pretty costly for order-4 allocation which will be used here as
struct vhost_net seems to be 36104 (at least in with my config). Have
you ever measured the difference?
So I am just trying to understand whether we should teach kvmalloc_node
to understand GFP_REPEAT or there is no strong reason to keep the repeat
flag.
[1] http://lkml.kernel.org/r/20170102133700.1734-1-mhocko@kernel.org
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-mm@kvack.org, virtualization@lists.linux-foundation.org
Subject: GFP_REPEAT usage in vhost_net_open resp. vhost_vsock_dev_open
Date: Wed, 4 Jan 2017 16:08:00 +0100 [thread overview]
Message-ID: <20170104150800.GO25453@dhcp22.suse.cz> (raw)
Hi Michael,
I am currently cleaning up opencoded kmalloc with vmalloc fallback users
[1] and my current kvmalloc_node helper doesn't support GFP_REPEAT
because there are no users which would need it. At least that's what I
thought until I've encountered vhost_vsock_dev_open resp.
vhost_vsock_dev_open which are trying to use GFP_REPEAT for kmalloc.
23cc5a991c7a ("vhost-net: extend device allocation to vmalloc") explains
the motivation as follows:
"
As vmalloc() adds overhead on a critical network path, add __GFP_REPEAT
to kzalloc() flags to do this fallback only when really needed.
"
I am wondering whether vmalloc adds more overhead than GFP_REPEAT which
can get pretty costly for order-4 allocation which will be used here as
struct vhost_net seems to be 36104 (at least in with my config). Have
you ever measured the difference?
So I am just trying to understand whether we should teach kvmalloc_node
to understand GFP_REPEAT or there is no strong reason to keep the repeat
flag.
[1] http://lkml.kernel.org/r/20170102133700.1734-1-mhocko@kernel.org
--
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 reply other threads:[~2017-01-04 15:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 15:08 Michal Hocko [this message]
2017-01-04 15:08 ` GFP_REPEAT usage in vhost_net_open resp. vhost_vsock_dev_open Michal Hocko
2017-01-04 17:56 ` Michael S. Tsirkin
2017-01-04 17:56 ` Michael S. Tsirkin
2017-01-04 18:06 ` Michal Hocko
2017-01-04 18:06 ` 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=20170104150800.GO25453@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=linux-mm@kvack.org \
--cc=mst@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/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.