Loss of several MB of run-time memory

[Brad Bishop]

> On Oct 9, 2018, at 6:25 PM, Joel Stanley <joel at jms.id.au> wrote:
> 
> On Wed, 10 Oct 2018 at 03:38, Kun Yi <kunyi at google.com> wrote:
>> 
>> A somewhat tedious way to test would be to build and boot with 'bitbake core-image-minimal' to ensure no phosphor-daemons are loaded, and then compare the kernel memory footprint.
>> 
>> On Tue, Oct 9, 2018 at 10:01 AM Tanous, Ed <ed.tanous at intel.com> wrote:
>>> 
>>> Was this only the kernel version jump, or did you jump in openbmc/phosphor levels as well?  There have been quite a few daemons added in the last 6 months or so that could explain your memory footprint increase.
> 
> HI team. Just a reminder about email etiquette on the mailing lists
> that Brad posted a while back:
> 
> https://fedoraproject.org/wiki/Mailing_list_guidelines#Proper_posting_style
> 
> In particular the top posting bit, which makes it hard to reply to this thread.
> 
> Back to the issue at hand:
> 
>>>> On Oct 9, 2018, at 9:54 AM, Patrick Venture <venture at google.com> wrote:
>>>> 
>>>> Just jumped from 4.7 kernel to 4.18 running the latest openbmc image
>>>> on the quanta-q71l board.  And I see now I have ~20MiB of RAM free for
>>>> stuff once things are settled, whereas before I could have up to
>>>> 35MiB.
> 
> Are you able to boot the new kernel with the old userspace? This will
> allow you to compare like for like (even if the system is not fully
> functional in that state). Alternatively, boot it with a small
> non-openbmc initrd to allow comparisons as Kun suggested.
> 
> The kernel has grown a bunch of new drivers. Most of them should not
> probe, and therefore won't allocate memory at run time, but there may
> be some new ones.
> 
> I've not spent much time looking at runtime memory usage, so if these
> suggestions don't provide answers we might need to investigate a bit
> deeper.
> 
>>>> This matters for a few reasons:
>>>> 1) my memory chip is too small to be practical and I need all the
>>>> bytes I can get.
>>>> 2) I need at least 32MiB to load a new firmware image.
>>>> 
>>>> I dropped all the python except the mapper, and I dropped the newer
>>>> daemons from my build to clear out that difference.  It was originally
>>>> about 16MiB difference, so I was thinking that something is now being
>>>> mapped by default that wasn't before, such as part of a flash image.
> 
> I initially thought you were confusing RAM with flash size, but on a
> second read I now understand.
> 
> There has been recent work to create phosphor-tiny, is that relevant here Brad?

No, at least not yet.  At the moment all phosphor-tiny does is remove all the python
source (leaving just the bytecode) - so flash footprint only.

> 
> Cheers,
> 
> Joel