Skip to contentSkip to conversation

Extend malloc() pool for Zynq devices

PATCH Superseded Anton Gerasimov 2 participants 8 messages Dec 20, 2018 – Jan 22, 2019

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover Extend malloc() pool for Zynq devices

I'm getting -ENOMEM on Z-Turn board already, other boards are probably still allright if no one complains, but might hit the limit soon.

Anton Gerasimov (1):
zynq: Kconfig: extend the bootstrap malloc() pool

 arch/arm/mach-zynq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Signature · 1 line
2.19.0
#1 lore raw

PATCH 1/1 zynq: Kconfig: extend the bootstrap malloc() pool

---
 arch/arm/mach-zynq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-zynq/Kconfig +1 -1
index a599ed63ee..21dfebf5c0 100644
@@ -55,7 +55,7 @@ config SYS_CONFIG_NAME
 	  will be used for board configuration.
 
 config SYS_MALLOC_F_LEN
-	default 0x600
+	default 0x800
 
 config SYS_MALLOC_LEN
 	default 0x1400000
Signature · 1 line
2.19.0
#2 lore raw

PATCH 1/1 zynq: Kconfig: extend the bootstrap malloc() pool

Quoted 11 lines · Anton Gerasimov
---
 arch/arm/mach-zynq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-zynq/Kconfig +0 -0
index a599ed63ee..21dfebf5c0 100644

arch/arm/mach-zynq/Kconfig config SYS_CONFIG_NAME · line 61

Quoted 8 lines
arch/arm/mach-zynq/Kconfig +1 -1
@@ -55,7 +55,7 @@ config SYS_CONFIG_NAME
 	  will be used for board configuration.
 
 config SYS_MALLOC_F_LEN
-	default 0x600
+	default 0x800
 
 config SYS_MALLOC_LEN
 	default 0x1400000

I have not a problem with this change but it has to be done based on more information. It means you should look what requires that memory and if make sense that these components need it at that time.

Note: in v2 please write reasonable commit message directly to the patch too.

Thanks,
Michal

#3 lore raw

PATCH 1/1 zynq: Kconfig: extend the bootstrap malloc() pool

Quoted 3 lines

I have not a problem with this change but it has to be done based on more information. It means you should look what requires that memory and if make sense that these components need it at that time.

Thank you for  the advice, that was quite fruitful. So most of the heap (0x5f4 of 0x600) before the relocation is being consumed in device_bind_common function which binds device tree entries to the drivers.

If I remove 'u-boot,dm-pre-alloc' from uart0 node, that is not being used as far as I can see, it drops to 0x5a0, which lets the board boot, but still looks pretty tight. So maybe it's worth extending the heap anyway unless you need more information to take the decision.

Thanks,
Anton

#4 lore raw

PATCH 1/1 zynq: Kconfig: extend the bootstrap malloc() pool

Quoted 9 lines · Anton Gerasimov
Quoted 3 lines

I have not a problem with this change but it has to be done based on more information. It means you should look what requires that memory and if make sense that these components need it at that time.

Thank you for  the advice, that was quite fruitful. So most of the heap (0x5f4 of 0x600) before the relocation is being consumed in device_bind_common function which binds device tree entries to the drivers.

Quoted 4 lines

If I remove 'u-boot,dm-pre-alloc' from uart0 node, that is not being used as far as I can see, it drops to 0x5a0, which lets the board boot, but still looks pretty tight. So maybe it's worth extending the heap anyway unless you need more information to take the decision.

I understand all of this but will be good to know what consumes that 0x5xx space and if we mark nodes properly that maybe something is not used and we should remove that marking.

It means expected data is that uarts consumes 0xXXX, axi 0xXXX, sd 0xXXX, etc.

Thanks,
Michal

#5 lore raw

PATCH 1/1 zynq: Kconfig: extend the bootstrap malloc() pool

Hi Michal,

Quoted 6 lines

I understand all of this but will be good to know what consumes that 0x5xx space and if we mark nodes properly that maybe something is not used and we should remove that marking.

It means expected data is that uarts consumes 0xXXX, axi 0xXXX, sd 0xXXX, etc.

measuring only the memory consumed in device_bind_common, I've got the following results (in decimal):

  root_driver:               108 mod_exp_sw:                108
  amba:                      120
  serial at e0000000 aka uart0: 112
  serial at e0001000 aka uart1: 88
  spi at e000d000 aka qspi:     120
  sdhci at e0100000 aka mmc0:   455
  sdhci at e0100000.blk:        208
  slcr at f8000000:             96
  clkc at 100:                  72
  (total)                    1487 = 0x5cf of 0x600

So the most memory is being consumed by mmc0 (not quite sure what is this '.blk' device, but it is probably also required), but it's not dominating, other seemingly useful devices also have a decent share.

Thanks,
Anton

#6 lore raw

PATCH 1/1 zynq: Kconfig: extend the bootstrap malloc() pool

Hi,

Quoted 24 lines · Anton Gerasimov

Hi Michal,

Quoted 6 lines

I understand all of this but will be good to know what consumes that 0x5xx space and if we mark nodes properly that maybe something is not used and we should remove that marking.

It means expected data is that uarts consumes 0xXXX, axi 0xXXX, sd 0xXXX, etc.

measuring only the memory consumed in device_bind_common, I've got the following results (in decimal):

  root_driver:               108 mod_exp_sw:                108
  amba:                      120
  serial at e0000000 aka uart0: 112
  serial at e0001000 aka uart1: 88
  spi at e000d000 aka qspi:     120
  sdhci at e0100000 aka mmc0:   455
  sdhci at e0100000.blk:        208
  slcr at f8000000:             96
  clkc at 100:                  72
  (total)                    1487 = 0x5cf of 0x600

Quoted 3 lines

So the most memory is being consumed by mmc0 (not quite sure what is this '.blk' device, but it is probably also required), but it's not dominating, other seemingly useful devices also have a decent share.

ok. Thanks for this list. I have extended that commit message with this and applied. We can look at these separately to find out if we can tune it a little bit.

Thanks,
Michal

#7 lore raw

PATCH v2 1/1 zynq: Kconfig: extend the bootstrap malloc() pool

In reply to Michal Simek

Most of the memory is being consumed by device binding code, more space needed for other data structures.

Z-turn board has already hit the limit, others may follow soon.

---
 arch/arm/mach-zynq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-zynq/Kconfig +1 -1
index a599ed63ee..21dfebf5c0 100644
@@ -55,7 +55,7 @@ config SYS_CONFIG_NAME
 	  will be used for board configuration.
 
 config SYS_MALLOC_F_LEN
-	default 0x600
+	default 0x800
 
 config SYS_MALLOC_LEN
 	default 0x1400000
Signature · 1 line
2.19.0