All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Marc Gonzalez <marc.w.gonzalez@free.fr>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Alexey Brodkin <alexey.brodkin@synopsys.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Tejun Heo <tj@kernel.org>, Mark Brown <broonie@kernel.org>
Subject: Re: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()
Date: Fri, 20 Dec 2019 11:22:56 +0100	[thread overview]
Message-ID: <20191220102256.GB2259862@kroah.com> (raw)
In-Reply-To: <20191220102218.GA2259862@kroah.com>

On Fri, Dec 20, 2019 at 11:22:18AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 20, 2019 at 11:19:27AM +0100, Marc Gonzalez wrote:
> > On 17/12/2019 16:30, Marc Gonzalez wrote:
> > 
> > > Commit a66d972465d15 ("devres: Align data[] to ARCH_KMALLOC_MINALIGN")
> > > increased the alignment of devres.data unconditionally.
> > > 
> > > Some platforms have very strict alignment requirements for DMA-safe
> > > addresses, e.g. 128 bytes on arm64. There, struct devres amounts to:
> > > 	3 pointers + pad_to_128 + data + pad_to_256
> > > i.e. ~220 bytes of padding.
> > > 
> > > Let's enforce the alignment only for devm_kmalloc().
> > > 
> > > Suggested-by: Robin Murphy <robin.murphy@arm.com>
> > > Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
> > > ---
> > > I had not been aware that dynamic allocation granularity on arm64 was
> > > 128 bytes. This means there's a lot of waste on small allocations.
> > > I suppose there's no easy solution, though.
> > > ---
> > >  drivers/base/devres.c | 23 +++++++++++++----------
> > >  1 file changed, 13 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> > > index 0bbb328bd17f..bf39188613d9 100644
> > > --- a/drivers/base/devres.c
> > > +++ b/drivers/base/devres.c
> > > @@ -26,14 +26,7 @@ struct devres_node {
> > >  
> > >  struct devres {
> > >  	struct devres_node		node;
> > > -	/*
> > > -	 * Some archs want to perform DMA into kmalloc caches
> > > -	 * and need a guaranteed alignment larger than
> > > -	 * the alignment of a 64-bit integer.
> > > -	 * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same
> > > -	 * buffer alignment as if it was allocated by plain kmalloc().
> > > -	 */
> > > -	u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
> > > +	u8				data[];
> > >  };
> > >  
> > >  struct devres_group {
> > > @@ -789,9 +782,16 @@ static void devm_kmalloc_release(struct device *dev, void *res)
> > >  	/* noop */
> > >  }
> > >  
> > > +#define DEVM_KMALLOC_PADDING_SIZE \
> > > +	(ARCH_KMALLOC_MINALIGN - sizeof(struct devres) % ARCH_KMALLOC_MINALIGN)
> > > +
> > >  static int devm_kmalloc_match(struct device *dev, void *res, void *data)
> > >  {
> > > -	return res == data;
> > > +	/*
> > > +	 * 'res' is dr->data (not DMA-safe)
> > > +	 * 'data' is the hand-aligned address from devm_kmalloc
> > > +	 */
> > > +	return res + DEVM_KMALLOC_PADDING_SIZE == data;
> > >  }
> > >  
> > >  /**
> > > @@ -811,6 +811,9 @@ void * devm_kmalloc(struct device *dev, size_t size, gfp_t gfp)
> > >  {
> > >  	struct devres *dr;
> > >  
> > > +	/* Add enough padding to provide a DMA-safe address */
> > > +	size += DEVM_KMALLOC_PADDING_SIZE;
> > > +
> > >  	/* use raw alloc_dr for kmalloc caller tracing */
> > >  	dr = alloc_dr(devm_kmalloc_release, size, gfp, dev_to_node(dev));
> > >  	if (unlikely(!dr))
> > > @@ -822,7 +825,7 @@ void * devm_kmalloc(struct device *dev, size_t size, gfp_t gfp)
> > >  	 */
> > >  	set_node_dbginfo(&dr->node, "devm_kzalloc_release", size);
> > >  	devres_add(dev, dr->data);
> > > -	return dr->data;
> > > +	return dr->data + DEVM_KMALLOC_PADDING_SIZE;
> > >  }
> > >  EXPORT_SYMBOL_GPL(devm_kmalloc);
> > 
> > Would anyone else have any suggestions, comments, insights, recommendations,
> > improvements, guidance, or wisdom? :-)
> > 
> > I keep thinking about the memory waste caused by the strict alignment requirement
> > on arm64. Is there a way to inspect how much memory has been requested vs how much
> > has been allocated? (Turning on SLAB DEBUG perhaps?)
> > 
> > Couldn't there be a kmalloc flag saying "this alloc will not require strict
> > alignment, so just give me something 8-byte aligned" ?
> 
> Or you can not use the devm interface for lots of tiny allocations :)

Oh nevermind, "normal" kmalloc allocations are all aligned that way
anyway, so that's not going to solve anything, sorry.

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Marc Gonzalez <marc.w.gonzalez@free.fr>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>,
	Alexey Brodkin <alexey.brodkin@synopsys.com>,
	Rafael Wysocki <rjw@rjwysocki.net>,
	LKML <linux-kernel@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Mark Brown <broonie@kernel.org>, Tejun Heo <tj@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()
Date: Fri, 20 Dec 2019 11:22:56 +0100	[thread overview]
Message-ID: <20191220102256.GB2259862@kroah.com> (raw)
In-Reply-To: <20191220102218.GA2259862@kroah.com>

On Fri, Dec 20, 2019 at 11:22:18AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 20, 2019 at 11:19:27AM +0100, Marc Gonzalez wrote:
> > On 17/12/2019 16:30, Marc Gonzalez wrote:
> > 
> > > Commit a66d972465d15 ("devres: Align data[] to ARCH_KMALLOC_MINALIGN")
> > > increased the alignment of devres.data unconditionally.
> > > 
> > > Some platforms have very strict alignment requirements for DMA-safe
> > > addresses, e.g. 128 bytes on arm64. There, struct devres amounts to:
> > > 	3 pointers + pad_to_128 + data + pad_to_256
> > > i.e. ~220 bytes of padding.
> > > 
> > > Let's enforce the alignment only for devm_kmalloc().
> > > 
> > > Suggested-by: Robin Murphy <robin.murphy@arm.com>
> > > Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
> > > ---
> > > I had not been aware that dynamic allocation granularity on arm64 was
> > > 128 bytes. This means there's a lot of waste on small allocations.
> > > I suppose there's no easy solution, though.
> > > ---
> > >  drivers/base/devres.c | 23 +++++++++++++----------
> > >  1 file changed, 13 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> > > index 0bbb328bd17f..bf39188613d9 100644
> > > --- a/drivers/base/devres.c
> > > +++ b/drivers/base/devres.c
> > > @@ -26,14 +26,7 @@ struct devres_node {
> > >  
> > >  struct devres {
> > >  	struct devres_node		node;
> > > -	/*
> > > -	 * Some archs want to perform DMA into kmalloc caches
> > > -	 * and need a guaranteed alignment larger than
> > > -	 * the alignment of a 64-bit integer.
> > > -	 * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same
> > > -	 * buffer alignment as if it was allocated by plain kmalloc().
> > > -	 */
> > > -	u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
> > > +	u8				data[];
> > >  };
> > >  
> > >  struct devres_group {
> > > @@ -789,9 +782,16 @@ static void devm_kmalloc_release(struct device *dev, void *res)
> > >  	/* noop */
> > >  }
> > >  
> > > +#define DEVM_KMALLOC_PADDING_SIZE \
> > > +	(ARCH_KMALLOC_MINALIGN - sizeof(struct devres) % ARCH_KMALLOC_MINALIGN)
> > > +
> > >  static int devm_kmalloc_match(struct device *dev, void *res, void *data)
> > >  {
> > > -	return res == data;
> > > +	/*
> > > +	 * 'res' is dr->data (not DMA-safe)
> > > +	 * 'data' is the hand-aligned address from devm_kmalloc
> > > +	 */
> > > +	return res + DEVM_KMALLOC_PADDING_SIZE == data;
> > >  }
> > >  
> > >  /**
> > > @@ -811,6 +811,9 @@ void * devm_kmalloc(struct device *dev, size_t size, gfp_t gfp)
> > >  {
> > >  	struct devres *dr;
> > >  
> > > +	/* Add enough padding to provide a DMA-safe address */
> > > +	size += DEVM_KMALLOC_PADDING_SIZE;
> > > +
> > >  	/* use raw alloc_dr for kmalloc caller tracing */
> > >  	dr = alloc_dr(devm_kmalloc_release, size, gfp, dev_to_node(dev));
> > >  	if (unlikely(!dr))
> > > @@ -822,7 +825,7 @@ void * devm_kmalloc(struct device *dev, size_t size, gfp_t gfp)
> > >  	 */
> > >  	set_node_dbginfo(&dr->node, "devm_kzalloc_release", size);
> > >  	devres_add(dev, dr->data);
> > > -	return dr->data;
> > > +	return dr->data + DEVM_KMALLOC_PADDING_SIZE;
> > >  }
> > >  EXPORT_SYMBOL_GPL(devm_kmalloc);
> > 
> > Would anyone else have any suggestions, comments, insights, recommendations,
> > improvements, guidance, or wisdom? :-)
> > 
> > I keep thinking about the memory waste caused by the strict alignment requirement
> > on arm64. Is there a way to inspect how much memory has been requested vs how much
> > has been allocated? (Turning on SLAB DEBUG perhaps?)
> > 
> > Couldn't there be a kmalloc flag saying "this alloc will not require strict
> > alignment, so just give me something 8-byte aligned" ?
> 
> Or you can not use the devm interface for lots of tiny allocations :)

Oh nevermind, "normal" kmalloc allocations are all aligned that way
anyway, so that's not going to solve anything, sorry.

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-12-20 10:23 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17 15:30 [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc() Marc Gonzalez
2019-12-17 15:30 ` Marc Gonzalez
2019-12-17 15:45 ` Greg Kroah-Hartman
2019-12-17 15:45   ` Greg Kroah-Hartman
2019-12-17 16:17 ` Marc Gonzalez
2019-12-17 16:17   ` Marc Gonzalez
2019-12-18 14:20 ` Alexey Brodkin
2019-12-18 14:20   ` Alexey Brodkin
2019-12-18 14:20   ` Alexey Brodkin
2019-12-18 15:40   ` Marc Gonzalez
2019-12-18 15:40     ` Marc Gonzalez
2019-12-18 15:40     ` Marc Gonzalez
2019-12-20 10:19 ` Marc Gonzalez
2019-12-20 10:19   ` Marc Gonzalez
2019-12-20 10:22   ` Greg Kroah-Hartman
2019-12-20 10:22     ` Greg Kroah-Hartman
2019-12-20 10:22     ` Greg Kroah-Hartman [this message]
2019-12-20 10:22       ` Greg Kroah-Hartman
2019-12-20 12:05       ` Marc Gonzalez
2019-12-20 12:05         ` Marc Gonzalez
2019-12-20 17:19         ` Peter Zijlstra
2019-12-20 17:19           ` Peter Zijlstra
2019-12-20 14:06   ` Peter Zijlstra
2019-12-20 14:06     ` Peter Zijlstra
2019-12-20 14:16     ` Greg Kroah-Hartman
2019-12-20 14:16       ` Greg Kroah-Hartman
2019-12-20 15:01     ` Robin Murphy
2019-12-20 15:01       ` Robin Murphy
2019-12-20 17:13       ` Peter Zijlstra
2019-12-20 17:13         ` Peter Zijlstra
2019-12-20 22:02         ` Robin Murphy
2019-12-20 22:02           ` Robin Murphy
2020-01-06 10:05           ` Peter Zijlstra
2020-01-06 10:05             ` Peter Zijlstra
2019-12-20 19:32       ` Alexey Brodkin
2019-12-20 19:32         ` Alexey Brodkin
2019-12-20 19:32         ` Alexey Brodkin
2019-12-20 20:23         ` Peter Zijlstra
2019-12-20 20:23           ` Peter Zijlstra
2019-12-20 20:23           ` Peter Zijlstra
2019-12-20 21:02           ` Alexey Brodkin
2019-12-20 21:02             ` Alexey Brodkin
2019-12-20 21:02             ` Alexey Brodkin
2019-12-20 21:47             ` Dmitry Torokhov
2019-12-20 21:47               ` Dmitry Torokhov
2019-12-20 21:47               ` Dmitry Torokhov

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=20191220102256.GB2259862@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alexey.brodkin@synopsys.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.w.gonzalez@free.fr \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robin.murphy@arm.com \
    --cc=tj@kernel.org \
    --cc=will@kernel.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.