[LEDE-DEV] [PATCH] kmodloader: don't store aliases info in struct module
Ted Hess
lede at kitschensync.net
Thu Feb 23 05:45:25 PST 2017
On Thu, 2017-02-23 at 11:25 +0800, Yousong Zhou wrote:
> This also fixes FS#544 as the allocation causing possible address alignment
> issue should now disappear
>
> Size comparison on x86_64 system
>
> function old new delta
> alloc_module 398 245 -153
> ------------------------------------------------------------------------
> ------
> (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-153) Total: -153
> bytes
>
> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
> ---
> Ted, please test it on your board to see if it can fix your issue.
>
> The patch was only run-tested on armvirt cortex-a15 machine.
>
> I actually thought about patching calloc_a to make sizeof_long-aligned
> allocation as the comment in libubox/utils.h says the func should "allocate a
> block of memory big enough to hold multiple aligned objects."
>
> But that's too corase a solution for a fundamental lib and can waste runtime
> memory. Maybe we should reword that comment and provide a few helper macros
> like SHORT_ALIGN, INT_ALIGN, LONG_ALIGN?
>
I was also thinking of making calloc_a() function as one would expect for a data
structure with embedded pointers and data. It serves as an memory efficient
method for handling multiple (atomic) allocations and makes the task of freeing
the object more straightforward. However, its current implementation ALWAYS
creates packed objects which is fine for a lot of architectures, but not all.
The alignment necessary is for pointers only since that is what it is
allocating. There must be some platform/architecture specific system macros
which can be used here.
That said, your patch is a much better workaround for the issue at hand than was
mine. I am concerned however, about the possibility of other problems lurking in
code using calloc_a() which haven't been discovered yet and would like to
advocate changing calloc_a() as a permanent fix. The memory and performance
impact would be minimal compared to using multiple allocations for the same
thing.
/ted
More information about the Lede-dev
mailing list