Heap size adjusted to work for both tls-client and mbed-client #3920

mazimkhan · 2017-03-10T11:23:35Z

Description

Targets NUCLEO_F429ZI and UBLOX_EVK_ODIN_W2 have 192K RAM.
Heap size in PR #3871 was increased from 48K to 96K as tls-client
example failed with 48K heap. But this resulted in compilation failures
in mbed-client that requires 71K for global/static data.
Hence this PR reduces heap to 64K that minimum required by tls-client
to work. This also meets mbed-client data segment requirements.

Migrations

If this PR changes any APIs or behaviors, give a short description of what API users should do when this PR is merged.

NO

Related PRs

#3871

branch	PR
other_pr_production	link
other_pr_master	link

Todos

Tests
Documentation

Deploy notes

Notes regarding the deployment of this PR. These should note any
required changes in the build environment, tools, compilers, etc.

Steps to test or reproduce

It should fix issue ARMmbed/mbed-os-example-client#194 (comment)
and build failure mentioned here ARMmbed/mbed-os-example-client#194 (comment)

@0xc0170 @SeppoTakalo

0xc0170 · 2017-03-10T11:40:15Z

targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F429xI/device/TOOLCHAIN_IAR/stm32f429xx_flash.icf

@@ -17,7 +17,7 @@ define symbol __ICFEDIT_region_CCMRAM_end__   = 0x1000FFFF;
 /*-Sizes-*/
 /*Heap 1/2 of ram and stack 1/8*/
 define symbol __ICFEDIT_size_cstack__ = 0x6000;
-define symbol __ICFEDIT_size_heap__   = 0x18000;


is it 1/2 of RAM (comment says so) ? Is it 1/4 as thats usual number ?

Let's make sure this new number works for all reported issues we had within last days, and any future failure shall be a known issue?

Preferably just remove those /*Heap 1/2 of ram and stack 1/8*/ and just tell the numbers, like /* 64kB of HEAP */

SeppoTakalo · 2017-03-13T09:52:04Z

Why do we reserve 24kB of stack?
I have only seen 6kB used in mesh or client examples, when they call mbed TLS. Most of the threads we are running use something like 1kB or 2kB.
24kB for main thread, that is mostly doing nothing, sound like a big.

I still feel like we are trying to tune this just for running the TLS example app.
For the heap, if IAR does not allow it to grow, 64kB sound OK.

yogpan01 · 2017-03-13T10:15:18Z

The heap size requirement depends on the application usage of mbed-client, if application decides to create huge number of resources it will increase the heap usage. So, this number is just to fit the current example application, but if someone wants to extend this application , they will run into problem again.

0xc0170 · 2017-03-14T09:31:38Z

Why do we reserve 24kB of stack?

mbed 2 that does not use RTOS, and this files come from cmsis and vendors. Thus I assume this is a default value they set it to.

I still feel like we are trying to tune this just for running the TLS example app.
For the heap, if IAR does not allow it to grow, 64kB sound OK.

The heap size requirement depends on the application usage of mbed-client, if application decides to create huge number of resources it will increase the heap usage. So, this number is just to fit the current example application, but if someone wants to extend this application , they will run into problem again.

Correct. This is a fix for the last commit that increased static heap size. It broke some apps as @mazimkhan described above. Thus this should be set for very last time to some sensible default, and apps needs to tune it to their needs (workaround until IAR gets dynamic sized heap). Does that sound fine?

@mazimkhan Travis CI does not report anything below. please have a look

mazimkhan · 2017-03-14T10:40:39Z

@0xc0170 I do not have access to travis. @bridadan can you please help?

0xc0170 · 2017-03-14T12:40:53Z

@0xc0170 I do not have access to travis. @bridadan can you please help?

I have just restarted it (it was green!)

bridadan · 2017-03-14T23:24:20Z

/morph test-nightly

mbed-bot · 2017-03-15T02:43:14Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1684

Test failed!

mazimkhan · 2017-03-15T09:37:19Z

Seems like a CI error in ci/morph-test-nightly

19:37:42 Process Process-1:
19:37:42 Traceback (most recent call last):
19:37:42   File "c:\python27\Lib\multiprocessing\process.py", line 258, in _bootstrap
19:37:42     self.run()
19:37:42   File "c:\python27\Lib\multiprocessing\process.py", line 114, in run
19:37:42     self._target(*self._args, **self._kwargs)
19:37:42   File "c:\mbed_jenkins\test_node_5\workspace\tm_wrap\1332\.env\lib\site-packages\mbed_host_tests\host_tests_conn_proxy\conn_proxy.py", line 209, in conn_process
19:37:42     data = connector.read(2304)
19:37:42   File "c:\mbed_jenkins\test_node_5\workspace\tm_wrap\1332\.env\lib\site-packages\mbed_host_tests\host_tests_conn_proxy\conn_primitive_serial.py", line 99, in read
19:37:42     time.sleep(self.timeout)
19:37:42 IOError: [Errno 4] Interrupted function call
19:54:30 Agent went offline during the build
19:54:30 ERROR: Connection was broken: java.io.IOException: Connection aborted: org.jenkinsci.remoting.nio.NioChannelHub$MonoNioTransport@2cffc47e[name=test_node_5]
19:54:30 	at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:208)
19:54:30 	at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:629)
19:54:30 	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
19:54:30 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
19:54:30 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
19:54:30 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
19:54:30 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
19:54:30 	at java.lang.Thread.run(Thread.java:745)
19:54:30 Caused by: java.io.IOException: Connection timed out
19:54:30 	at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
19:54:30 	at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
19:54:30 	at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
19:54:30 	at sun.nio.ch.IOUtil.read(IOUtil.java:197)
19:54:30 	at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:384)
19:54:30 	at org.jenkinsci.remoting.nio.FifoBuffer$Pointer.receive(FifoBuffer.java:137)
19:54:30 	at org.jenkinsci.remoting.nio.FifoBuffer.receive(FifoBuffer.java:310)
19:54:30 	at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:561)
19:54:30 	... 6 more
19:54:30 
19:54:30 Build step 'Execute shell' marked build as failure

0xc0170 · 2017-03-15T10:26:12Z

/morph test-nightly

0xc0170 · 2017-03-15T10:28:20Z

@mazimkhan Can you rebase this or just do a small change to restart travis? I manually restarted it yesterday, it's green for this PR but does not report back to github, see the results https://travis-ci.org/ARMmbed/mbed-os/jobs/209713138/config

SeppoTakalo · 2017-03-15T10:40:15Z

This commit reverts back only the F429. Not the Ublox, should it be added here also?

SeppoTakalo · 2017-03-15T10:45:20Z

Also, I'm really skeptical that we would ever need 24kB of stack on RTOS environment.

This "stack" is not all stacks combined, it is the main stack. All other thread have their own stacks, reserved at compile time (or dynamically).
Most applications probably do while(1) {...} on their main thread, so most of the work is already done in other threads.

Why did you come up with the number 24kB? How did you measure it?
What I'm saying is that maybe we can save over 10kB of RAM by lowering the stack value also. Biggest usage I have seen so far is 6kB on thread using mbed TLS.

mazimkhan · 2017-03-15T10:53:20Z

@SeppoTakalo you are right. But to be compatible with mbed 2.0 we need to leave this. If it was GCC or ARM where stack is located on top and can grow it was ok to reduce it. But in IAR the stack is in the middle and need to be fixed. Hence 24kB is only left for mbed 2.0

Targets NUCLEO_F429ZI and UBLOX_EVK_ODIN_W2 have 192K RAM. Heap size in PR ARMmbed#3871 was increased from 48K to 96K as tls-client example failed with 48K heap. But this resulted in compilation failures in mbed-client that requires 71K for global/static data. Hence this PR reduces heap to 64K that minimum required by tls-client to work. This also meets mbed-client data segment requirements.

SeppoTakalo · 2017-03-15T11:36:33Z

Practically stack always grows down, no matter where it is located. (True on ARM, Thumb/Thumb2, X86. Originally ARM supported growing up)
Mostly it is therefore located in top of the RAM. But it always need statically allocated free space under it, where to grow. Its not compiler dependant thing. However, heap also grows, at least in GCC and ARM.

But.. This only one of the stacks. That only stands for mbed OS 2, when there are no threads.
With RTOS, we have one stack per thread, and only one of them is located in the top. All others are located, as you said for IAR, in the middle. Somewhere in the .data or .bss sections.

So far I have spotted following threads inside mbed OS:

As you can see, all these statically allocate their own space for the stack. And are not part of the 24kB you are allocating. And all of the are "in the middle". And all of them are able to run on smaller than 24kB. The 6kB one is the one that calls mbed TLS. Thats why I want to know what requires 24kB on this exact platform. For me, it looks like we are just wasting memory.

mazimkhan · 2017-03-15T11:51:36Z

The linker files in this PR are for IAR. Hence we only need to discuss IAR. Please see IAR stack location explained here https://www.iar.com/kr/support/resources/articles/mastering-stack-and-heap-for-system-reliability/

You are right it is complete waste of memory with RTX in mbed-os 5. 24kB is only specific to IAR on mbed-os 2. We don't know how much stack is used by mbed-os 2.

SeppoTakalo · 2017-03-15T11:58:35Z

Your document does not directly apply.
RTX takes over after the bootstrap, it defines the threads and stacks.

RTX threads:

All those allocate their own stack, somewhere from .data or .bss. So in the end, I don't know if anything other than interrupts end up using the stack you are defining.

Have I misunderstood now something, you say that 24kB is only specific to IAR on mbed-os 2 but the linker files are the same. So the complete 24kB goes into waste in mbed OS 5.

mazimkhan · 2017-03-15T12:05:31Z

@SeppoTakalo I understand what you are saying about the RTX and mbed-os 5. But I don't understand what you are proposing for mbed-os 2 to work.
We have common linker files for mbed os 2 and 5. In this particular context it make this problem of wastage worse.

If I ask you a hypothetically question: Assume mbed-os 2 needs 24kB of stack. What should we put in the IAR liker file?

SeppoTakalo · 2017-03-15T12:09:52Z

If mbed OS 2 required 24kB, then we put 24kB.
The discussion started when I tried to ask a question that where did you come up with this number? For me, it sounds a quite big for system without threads or events.

SeppoTakalo · 2017-03-15T12:12:13Z

For optimal case, this should be configurable by application, because it is application depend. Not even platform depend.
So the whole stack size should be set by application, or OS with sensible default.
Now we are fine tuning just one particular platform.

mazimkhan · 2017-03-15T13:07:19Z

This is exactly what I have said here ARMmbed/mbed-os-example-client#194 (comment)

We didn't come up with this number. It was there by default.
I just checked K64F https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_IAR/MK64FN1M0xxx12.icf
That is even bigger 32kB.

0xc0170 · 2017-03-15T13:41:33Z

The discussion started when I tried to ask a question that where did you come up with this number? For me, it sounds a quite big for system without threads or events.

It's part of the linker file that comes from vendors. They define these values and use those in their apps or drivers. In the most cases, these numbers are not changed for mbed in most cases (my assumption as I even did not change those when I ported a target to mbed).

SeppoTakalo · 2017-03-15T13:45:25Z

OK.
Actually, the whole discussion is already irrelevant to this PR.
I searched and looks like we have very wide variety of stack sizes starting from 512kB (on NXP KL05Z) to 32kB. So, if this will be changed, it is not in this PR.

This PR fixes the build issue we have in mesh-minimal application when using IAR on UBLOX_EVK_ODIN_W2

mbed-bot · 2017-03-15T14:30:33Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1686

Test failed!

bridadan · 2017-03-15T16:36:10Z

/morph test-nightly

mbed-bot · 2017-03-15T21:10:26Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1689

All builds and test passed!

Ports for Upcoming Targets 3934: [Silicon Labs] Update to HAL and devices ARMmbed/mbed-os#3934 Known Issues There is an issue with LPC1768 failing the 'Semihost file system' test with this release. Fixes and Changes 3691: [TLS / hw acceleration] AES ECB for NUCLEO_F439ZI ARMmbed/mbed-os#3691 3869: NCS36510: Default range changed from 0 to 950mV - ADC ARMmbed/mbed-os#3869 3893: [STM32F7] Update STM32 Cube version v1.6.0 ARMmbed/mbed-os#3893 3917: Fix mistake register setting in serial_format() ARMmbed/mbed-os#3917 3927: [DELTA_DFBM_NQ620] Add RC calibration setting and revise mbed_overrides.c ARMmbed/mbed-os#3927 3918: [NUC472/M453] Support unique locally administered MAC address and other driver updates ARMmbed/mbed-os#3918 3920: Heap size adjusted to work for both tls-client and mbed-client ARMmbed/mbed-os#3920 3969: NUCLEO_F302R8: Add missing PB_8/PB_9 CAN pins ARMmbed/mbed-os#3969

0xc0170 reviewed Mar 10, 2017

View reviewed changes

mazimkhan force-pushed the master branch from dc0b16e to 7359247 Compare March 10, 2017 15:48

0xc0170 added the needs: review label Mar 14, 2017

mazimkhan force-pushed the master branch from 7359247 to 5a9ea2c Compare March 15, 2017 11:24

SeppoTakalo approved these changes Mar 15, 2017

View reviewed changes

bridadan mentioned this pull request Mar 15, 2017

[UBLOX_EVK_ODIN_W2 + IAR] Fails to register over WiFi ARMmbed/mbed-os-example-client#194

Closed

0xc0170 approved these changes Mar 16, 2017

View reviewed changes

0xc0170 added ready for merge and removed needs: review labels Mar 16, 2017

sg- merged commit 3d50554 into ARMmbed:master Mar 22, 2017

sg- added release-version: 5.4.2 and removed ready for merge labels Mar 22, 2017

jeromecoutant mentioned this pull request Mar 27, 2017

STM32 increase IAR heap size for big RAM targets #4031

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Heap size adjusted to work for both tls-client and mbed-client #3920

Heap size adjusted to work for both tls-client and mbed-client #3920

mazimkhan commented Mar 10, 2017 •

edited by 0xc0170

Loading

0xc0170 Mar 10, 2017

SeppoTakalo Mar 10, 2017

mazimkhan Mar 10, 2017

SeppoTakalo commented Mar 13, 2017

yogpan01 commented Mar 13, 2017

0xc0170 commented Mar 14, 2017 •

edited

Loading

mazimkhan commented Mar 14, 2017

0xc0170 commented Mar 14, 2017

bridadan commented Mar 14, 2017

mbed-bot commented Mar 15, 2017

mazimkhan commented Mar 15, 2017

0xc0170 commented Mar 15, 2017

0xc0170 commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

mazimkhan commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017 •

edited

Loading

mazimkhan commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

mazimkhan commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

mazimkhan commented Mar 15, 2017

0xc0170 commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

mbed-bot commented Mar 15, 2017

bridadan commented Mar 15, 2017

mbed-bot commented Mar 15, 2017

Heap size adjusted to work for both tls-client and mbed-client #3920

Heap size adjusted to work for both tls-client and mbed-client #3920

Conversation

mazimkhan commented Mar 10, 2017 • edited by 0xc0170 Loading

Description

Migrations

Related PRs

Todos

Deploy notes

Steps to test or reproduce

0xc0170 Mar 10, 2017

Choose a reason for hiding this comment

SeppoTakalo Mar 10, 2017

Choose a reason for hiding this comment

mazimkhan Mar 10, 2017

Choose a reason for hiding this comment

SeppoTakalo commented Mar 13, 2017

yogpan01 commented Mar 13, 2017

0xc0170 commented Mar 14, 2017 • edited Loading

mazimkhan commented Mar 14, 2017

0xc0170 commented Mar 14, 2017

bridadan commented Mar 14, 2017

mbed-bot commented Mar 15, 2017

Result: FAILURE

Output

mazimkhan commented Mar 15, 2017

0xc0170 commented Mar 15, 2017

0xc0170 commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

mazimkhan commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017 • edited Loading

mazimkhan commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

mazimkhan commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

mazimkhan commented Mar 15, 2017

0xc0170 commented Mar 15, 2017

SeppoTakalo commented Mar 15, 2017

mbed-bot commented Mar 15, 2017

Result: FAILURE

Output

bridadan commented Mar 15, 2017

mbed-bot commented Mar 15, 2017

Result: SUCCESS

Output

mazimkhan commented Mar 10, 2017 •

edited by 0xc0170

Loading

0xc0170 commented Mar 14, 2017 •

edited

Loading

SeppoTakalo commented Mar 15, 2017 •

edited

Loading