Loss of several MB of run-time memory

[Patrick Venture]

On Tue, Oct 9, 2018 at 3: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.

I'm going to try building an older kernel with the newer userspace
first (it's a slightly easier experiment).  I'll post back on this
thread once I have a little more information.

>
> 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