Messages in this thread | | | Subject | Re: [PATCH] dma-debug: dynamic allocation of hash table | From | Robin Murphy <> | Date | Fri, 31 Jan 2020 11:33:48 +0000 |
| |
On 2020-01-31 9:06 am, Geert Uytterhoeven wrote: > Hi Robin, > > On Fri, Jan 31, 2020 at 12:46 AM Robin Murphy <robin.murphy@arm.com> wrote: >> On 2020-01-30 7:10 pm, Eric Dumazet via iommu wrote: >>> Increasing the size of dma_entry_hash size by 327680 bytes >>> has reached some bootloaders limitations. >> >> [ That might warrant some further explanation - I don't quite follow how >> this would relate to a bootloader specifically :/ ] > > Increasing the size of a static array increases kernel size. > Some (all? ;-) bootloaders have limitations on the maximum size of a > kernel image they can boot (usually something critical gets overwritten > when handling a too large image). While boot loaders can be fixed and > upgraded, this is usually much more cumbersome than updating the > kernel.
Ah, OK - I'm all too familiar with bootloaders having image size limits, but I'm also used to implicitly-initialised statics being collected into a runtime-initialised .bss section, so I hadn't realised that there might still be platforms where that space is actually allocated in the image at link-time.
> Besides, a static array always consumes valuable unswapable memory, > even when the feature would not be used (e.g. disabled by a command > line option).
Indeed, and that alone might have been a reasonable rationale for the patch - I was merely querying the wording of the commit message, not its intent :)
Thanks, Robin.
| |