> - Tiny in RAM versus tiny on storage.
> - How much the kernel has grown over time.
> - How size regressions happen and how to avoid them
> - Size measurement, bloat-o-meter, allnoconfig, and other tools

Besides the discussions about keeping the kernel size small by
deselecting features, I believe we have a few options left to reduce the
size just by rethinking how data is arranged. I have just started to
research 'strings' in the kernel and am already seeing patterns which
look like low hanging fruits to me. (Unsurprisingly, given the amount of
copy&paste code.) Take the OOM message removal as one example, such
things can be fixed and prevented. Although my focus is 'strings'
currently, I am sure the lessons learned can be of generic interest. So
to say: keep the bloat on a level that is really needed for a new
feature.

I proposed to present my results at LinuxCon anyhow, so that would fit.

Disclaimer: Yes, I work more on drivers than core code :)