Re: [RFC] MAX_RESERVED_REGIONS hard-coded value

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Rob, Miles,

Thank you both for your replies.

On Wed, Jan 8, 2020 at 6:45 AM Miles Chen <miles.chen@xxxxxxxxxxxx> wrote:
>
> Hi,
>
> On Tue, 2020-01-07 at 15:13 -0600, Rob Herring wrote:
> > On Mon, Jan 6, 2020 at 12:05 PM Daniele Alessandrelli
> > <daniele.alessandrelli@xxxxxxxxx> wrote:
> > >
> > > Hi,
> > >
> > > I'm using a Device Tree with more then 32 reserved memory regions and
> > > I'm seeing the following error while booting the Kernel:
> > > [    0.000000] OF: reserved mem: not enough space all defined regions.
> >
> > How many do you have? Is that DT available somewhere?

Unfortunately, the DT is not publicly available yet. Anyway, I
currently have 41 reserved memory regions.

> >
> > > My understanding is that this is due to the hard-coded value of
> > > MAX_RESERVED_REGIONS in drivers/of/of_reserved_mem.c
> > >
> > > Googling around, I found this old discussion [1] in which Miles
> > > suggests to add a CONFIG_MAX_OF_RESERVED_REGIONS kconfig option to
> > > configure MAX_RESERVED_REGIONS. Rob replied to Miles' email saying
> > > that he would prefer MAX_RESERVED_REGIONS to be dynamic. However,
> > > later in the thread, it looks like making MAX_RESERVED_REGIONS dynamic
> > > poses some implementation issues [2]. At that point the discussion
> > > seemed to have stopped.
> >
> > Not sure what the problem was as there's no code, but I'd guess the
> > array alloc and populating have to be done later (perhaps in
> > unflattening).
>
> I missed my draft patch.
>
> From what I recall, the problem I had that time is that
> early_init_fdt_scan_reserved_mem() is called before paging_init(). So I
> cannot allocate accessible memory in early_init_fdt_scan_reserved_mem().
>
> For example: aarch64 setup_arch()
> setup_arch()
> {
>     memblock_init(); /* early_init_fdt_scan_reserved_mem() is called */
>     paging_init(); /* map memory */
> }
>
> >
> > > Is there any chance for the patch proposed by Miles to be reconsidered?
> >
> > A kconfig option would still be my 3rd choice after dynamically
> > allocating the array or just growing the fixed array size.

I'm happy with just growing the fixed array size, but just out of
curiosity, why do you prefer it to the kconfig option?

>
> Not sure how many of reserve memory regions Daniele has. In my case,
> we grow the MAX_RESERVED_REGIONS to 64 (3x used) and we are still trying
> to suppress the amount of reserved memory to fit
> MAX_RESERVED_REGIONS=32.

64 would be a safe value for my case as well.

We are also trying to reduce the amount of memory regions, but it's
unlikely we will manage to stay below 32 :/

Regards,
Daniele

>
>
>
> thanks,
> Miles
> >
> > Rob
>



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux