All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Gonzalez <marc.w.gonzalez@free.fr>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 13:05:43 +0100	[thread overview]
Message-ID: <5b12b473-bf9a-6dc9-838c-f9312eb10635@free.fr> (raw)
In-Reply-To: <20191220102256.GB2259862@kroah.com>

On 20/12/2019 11:22, Greg Kroah-Hartman wrote:

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

(For some context, and for what it's worth, my opinion is that device-managed
deallocation is the best thing since sliced bread.)

Typical devm use-case is:
1) user allocates a resource
2) user registers release_func+resource_context to devm

So typically, only 2 pointers (which is no issue when the alignment
requirement is 8 bytes). By nature, these are "small" allocations.

devm_kmalloc does not follow this pattern, it is a kind of optimization.
1) user does not allocate the resource (RAM)...
2) ...because the devm framework "merges" the user's memory request with
its own memory request for storing metadata -- as a memory allocator does
when it stores metadata for the request "in front of" the memory block.
(this is the reason why devm_kmalloc_release() is a noop)


(The following is just random thinking out loud)

If "fixing" the kmalloc strict alignment requirement on arm64 is too
hard, maybe it would be possible to shave some of the devm memory
waste by working with (chained) arrays of devm nodes, instead
of a straight-up linked list. (Akin to a C++ vector) Removal would
be expensive, but that's supposed to be a rare operation, right?

Regards.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Gonzalez <marc.w.gonzalez@free.fr>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 13:05:43 +0100	[thread overview]
Message-ID: <5b12b473-bf9a-6dc9-838c-f9312eb10635@free.fr> (raw)
In-Reply-To: <20191220102256.GB2259862@kroah.com>

On 20/12/2019 11:22, Greg Kroah-Hartman wrote:

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

(For some context, and for what it's worth, my opinion is that device-managed
deallocation is the best thing since sliced bread.)

Typical devm use-case is:
1) user allocates a resource
2) user registers release_func+resource_context to devm

So typically, only 2 pointers (which is no issue when the alignment
requirement is 8 bytes). By nature, these are "small" allocations.

devm_kmalloc does not follow this pattern, it is a kind of optimization.
1) user does not allocate the resource (RAM)...
2) ...because the devm framework "merges" the user's memory request with
its own memory request for storing metadata -- as a memory allocator does
when it stores metadata for the request "in front of" the memory block.
(this is the reason why devm_kmalloc_release() is a noop)


(The following is just random thinking out loud)

If "fixing" the kmalloc strict alignment requirement on arm64 is too
hard, maybe it would be possible to shave some of the devm memory
waste by working with (chained) arrays of devm nodes, instead
of a straight-up linked list. (Akin to a C++ vector) Removal would
be expensive, but that's supposed to be a rare operation, right?

Regards.

_______________________________________________
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 12:05 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
2019-12-20 10:22       ` Greg Kroah-Hartman
2019-12-20 12:05       ` Marc Gonzalez [this message]
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=5b12b473-bf9a-6dc9-838c-f9312eb10635@free.fr \
    --to=marc.w.gonzalez@free.fr \
    --cc=alexey.brodkin@synopsys.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.