在 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@xxxxxxxxxxxxx>
Reviewed-by: Boris Fiuczynski <fiuczy@xxxxxxxxxxxxxxxxxx>
Reviewed-by: Bjoern Walk <bwalk@xxxxxxxxxxxxxxxxxx>
Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>
---
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?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
