[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b12b473-bf9a-6dc9-838c-f9312eb10635@free.fr>
Date: Fri, 20 Dec 2019 13:05:43 +0100
From: Marc Gonzalez <marc.w.gonzalez@...e.fr>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Rafael Wysocki <rjw@...ysocki.net>,
LKML <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Robin Murphy <robin.murphy@....com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Alexey Brodkin <alexey.brodkin@...opsys.com>,
Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will@...nel.org>,
Russell King <rmk+kernel@...linux.org.uk>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Tejun Heo <tj@...nel.org>, Mark Brown <broonie@...nel.org>
Subject: Re: [RFC PATCH v1] devres: align devres.data strictly only for
devm_kmalloc()
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.
Powered by blists - more mailing lists