linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* GFP_REPEAT usage in vhost_net_open resp. vhost_vsock_dev_open
@ 2017-01-04 15:08 Michal Hocko
  2017-01-04 17:56 ` Michael S. Tsirkin
  0 siblings, 1 reply; 3+ messages in thread
From: Michal Hocko @ 2017-01-04 15:08 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: linux-mm, virtualization

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>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: GFP_REPEAT usage in vhost_net_open resp. vhost_vsock_dev_open
  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 18:06   ` Michal Hocko
  0 siblings, 1 reply; 3+ messages in thread
From: Michael S. Tsirkin @ 2017-01-04 17:56 UTC (permalink / raw)
  To: Michal Hocko; +Cc: linux-mm, virtualization

On Wed, Jan 04, 2017 at 04:08:00PM +0100, Michal Hocko wrote:
> 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

Yes but the GFP_REPEAT overhead is during allocation time.
Using vmalloc means all accesses are slowed down.
Allocation is not on data path, accesses are.

> 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?

I think it was measureable.

> 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>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: GFP_REPEAT usage in vhost_net_open resp. vhost_vsock_dev_open
  2017-01-04 17:56 ` Michael S. Tsirkin
@ 2017-01-04 18:06   ` Michal Hocko
  0 siblings, 0 replies; 3+ messages in thread
From: Michal Hocko @ 2017-01-04 18:06 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: linux-mm, virtualization

On Wed 04-01-17 19:56:42, Michael S. Tsirkin wrote:
> On Wed, Jan 04, 2017 at 04:08:00PM +0100, Michal Hocko wrote:
> > 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
> 
> Yes but the GFP_REPEAT overhead is during allocation time.
> Using vmalloc means all accesses are slowed down.
> Allocation is not on data path, accesses are.

OK, that wasn't clear to me. Thanks for the clarification. If the access
path can compensate the allocation cost then I agree that GFP_REPEAT
makes a lot of sense. I will cook up a patch to allow GFP_REPEAT in the
current kvmalloc_node and convert vhost users to it.

Thanks!

-- 
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>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-01-04 18:06 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 18:06   ` Michal Hocko

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).