Re: [PATCH] memory: transaction API

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

 



On 07/21/2011 01:38 PM, Jan Kiszka wrote:
On 2011-07-21 12:21, Avi Kivity wrote:
>  Allow changes to the memory hierarchy to be accumulated and
>  made visible all at once.  This reduces computational effort,
>  especially when an accelerator (e.g. kvm) is involved.
>
>  Useful when a single register update causes multiple changes
>  to an address space.

That's simple to implement in the core, but complicates life for the
users, at least for the simple "update this region" use case.


Why? just stick a _begin() and _commit() at the start and end of the update_mapping() function. It's an optional API, for simple cases (like mapping a BAR) you don't have to use it.


Do we have transactional scenarios during runtime where multiple memory
regions are reconfigured?

Both cirrus and 440fx PAM, I believe. They don't check for the "no change" condition (at least, not completely) and instead override the previous mapping.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux