[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [RFC PATCH] hw/arm/virt: use variable size o

From: Laszlo Ersek
Subject: Re: [Qemu-arm] [Qemu-devel] [RFC PATCH] hw/arm/virt: use variable size of flash device to save memory
Date: Tue, 26 Mar 2019 18:10:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 03/26/19 17:39, Markus Armbruster wrote:
> Laszlo Ersek <address@hidden> 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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]