[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH 4/6] pseries: Move hash page table allocation to r

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH 4/6] pseries: Move hash page table allocation to reset time
Date: Mon, 8 Feb 2016 15:44:18 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 02/05/2016 01:13 PM, David Gibson wrote:
At the moment the size of the hash page table (HPT) is fixed based on the
maximum memory allowed to the guest.  As such, we allocate the table during
machine construction, and just clear it at reset.

However, we're planning to implement a PAPR extension allowing the hash
page table to be resized at runtime.  This will mean that on reset we want
to revert it to the default size.  It also means that when migrating, we
need to make sure the destination allocates an HPT of size matching the
host, since the guest could have changed it before the migration.

This patch replaces the spapr_alloc_htab() and spapr_reset_htab() functions
with a new spapr_reallocate_hpt() function.  This is called at reset and
inbound migration only, not during machine init any more.

I'd suggest splitting this patch in two (move spapr_hpt_shift_for_ramsize to a new patch, or reorganizing it somehow (move spapr_hpt_shift_for_ramsize to a different place) - this one is really hard to read and make sure that nothing is lost.

In addition, we add a new helper to compute the recommended hash table size
for a given RAM size.  We export this as well as spapr_reallocate_hpt(),
since we'll be needing them elsewhere in future.

Do you already have a patch in your queue to exploit this?

I was told few times to export stuff when I have to...


reply via email to

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