[libvirt] [PATCH v3 06/12] conf: Introduce address caching for PCI extensions
Yi Min Zhao
zyimin at linux.ibm.com
Mon Aug 20 08:32:47 UTC 2018
在 2018/8/16 下午11:03, Andrea Bolognani 写道:
> On Tue, 2018-08-07 at 17:10 +0800, Yi Min Zhao wrote:
>> This patch provides a caching mechanism for the device address
>> extensions uid and fid on S390. For efficient sparse address allocation,
>> we introduce two hash tables for uid/fid which hold the address set
>> information per domain. Also in order to improve performance of
>> searching available value, we introduce our own callbacks for the two
>> hashtables. In this way, uid/fid is saved in hash key and hash value
>> could be any non-NULL pointer due to no operation on hash value. That is
>> also the reason why we don't introduce hash value free callback.
>>
>> Signed-off-by: Yi Min Zhao <zyimin at linux.ibm.com>
>> Reviewed-by: Boris Fiuczynski <fiuczy at linux.vnet.ibm.com>
>> Reviewed-by: Bjoern Walk <bwalk at linux.vnet.ibm.com>
>> Reviewed-by: Ján Tomko <jtomko at redhat.com>
>> ---
>> src/conf/domain_addr.c | 85 ++++++++++++++++++++++++++++++++++++++++++
>> src/conf/domain_addr.h | 9 +++++
>> src/libvirt_private.syms | 1 +
>> src/qemu/qemu_domain_address.c | 7 ++++
>> 4 files changed, 102 insertions(+)
> I haven't looked into the hash table handling in detail but I
> wonder if it's really necessary? IIUC you're using it just to
> mark which uids and fids have been already used by a device,
> which the PCI address allocation code does by setting bits
> inside integer variables - having a custom hash table for the
> same seems like overkill, and from the maintenance point of
> view it would be great to have the logic for PCI address and
> zPCI address allocation be similar unless diverging is strictly
> necessary.
>
PCI address set uses array to store pci addresses' assignment. It doesn't
need too much memory because the buses are allocated dynamically, one
bus only has 32 slot, and it's a tree topology. But in zpci case, fid
and uid
are flat. FID is 32-bit so that we need a 4294967295 sized array.
Don't you think it's too large?
More information about the libvir-list
mailing list