On 18.07.2011, at 18:18, Scott Wood wrote:
> On Mon, 18 Jul 2011 12:09:53 +0200
> Alexander Graf <agraf@xxxxxxx> wrote:
>
>> On 08.07.2011, at 01:41, Scott Wood wrote:
>>
>>> +void kvmppc_core_heavy_exit(struct kvm_vcpu *vcpu)
>>> +{
>>> + struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>>> + int i;
>>> +
>>> + /*
>>> + * We may have modified the guest TLB, so mark it dirty.
>>> + * We only do it on an actual return to userspace, to avoid
>>> + * adding more overhead to getting scheduled out -- and avoid
>>> + * any locking issues with getting preempted in the middle of
>>> + * KVM_CONFIG_TLB, etc.
>>> + */
>>> +
>>> + for (i = 0; i < vcpu_e500->num_shared_tlb_pages; i++)
>>> + set_page_dirty_lock(vcpu_e500->shared_tlb_pages[i]);
>>
>> Does this work? Why do we need to set them dirty in the first place? If the shared tlb pages are on file backed storage, we're screwed under memory pressure either way and they'd just get evicted despite us writing to them. Or does vmap pin them? Either way, they're either pinned or not. And if they're not, dirtying them here shouldn't really buy us anything, no?
>
> They're pinned by get_user_pages_fast(). We (potentially) write to them, so
> we should mark them dirty, because they are dirty. It's up to the rest
> of Linux what to do with that. Will being pinned stop updates from being
> written out if it is file-backed? And eventually the vm will be destroyed
> (or the tlb reconfigured) and the pages will be unpinned.
Hrm. How much overhead do we add to the exit-to-userspace path with this? I completely agree that we should mark them dirty when closing, but I'm not fully convinced a "we dirty them so we should declare them dirty at random times" pays off against possible substantial slowdowns due to the marking. Keep in mind that this is the MMIO case which isn't _that_ seldom.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
