On 03/26/19 17:39, Markus Armbruster wrote: > Laszlo Ersek <ler...@redhat.com> writes:
>> With the dynamic sizing in QEMU (which, IIRC, I had originally >> introduced still in the 1MB times, due to the split between the >> executable and varstore parts), both the 1MB->2MB switch, and the >> 2MB->4MB switch in the firmware caused zero pain in QEMU. And right now, >> 4MB looks like a "sweet spot", with some elbow room left. > > Explicit configuration would've been exactly as painless. Even with > pflash sizes restricted to powers of two. I wrote the patch that ended up as commit 637a5acb46b3 -- with your R-b -- in 2013. I'm unsure if machine type properties existed back then, but even if they did, do you think I knew about them? :) You are right, of course; it's just that we can't tell the future. >> Second, regarding physical RAM consumption: disable memory overcommit, >> and set a large swap. The unused parts of the large pflash chips should >> be swapped out at some point (after their initial population from disk), >> and should never be swapped back in again. > > Just providing swap should do the trick, shouldn't it? Yes, it should. (I just find any given swap setting more trustworthy if memory overcommit is disabled -- for me, disabling memory overcommit comes first. I trust "this swap should be large enough" much more if the kernel enforces allocations and the OOM killer can't surprise me later. I know we don't check g_malloc/g_new in QEMU, but I still prefer if those crash QEMU over the OOM killer picking a victim.) Thanks, Laszlo
