Loss of several MB of run-time memory

Joel Stanley joel at jms.id.au
Wed Oct 10 09:25:33 AEDT 2018


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?

Cheers,

Joel


More information about the openbmc mailing list