Il 17/09/2014 18:58, Andres Lagar-Cavilla ha scritto:
> Understood. So in patch 1, would kvm_gup_retry be ... just a wrapper
> around gup? That looks thin to me, and the naming of the function will
> not be accurate.
Depends on how you interpret "retry" ("with retry" vs. "retry after
_fast"). :)
On Wed, Sep 17, 2014 at 10:21 AM, Gleb Natapov wrote:
> On Wed, Sep 17, 2014 at 10:13:45AM -0700, Andres Lagar-Cavilla wrote:
>> On Wed, Sep 17, 2014 at 10:08 AM, Gleb Natapov wrote:
>> > On Wed, Sep 17, 2014 at 10:00:32AM -0700, Andres Lagar-Cavilla wrote:
>> >> On Wed, Sep 17, 2014 at 4:42 AM,
On Wed, Sep 17, 2014 at 10:13:45AM -0700, Andres Lagar-Cavilla wrote:
> On Wed, Sep 17, 2014 at 10:08 AM, Gleb Natapov wrote:
> > On Wed, Sep 17, 2014 at 10:00:32AM -0700, Andres Lagar-Cavilla wrote:
> >> On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov wrote:
> >> > On Wed, Sep 17, 2014 at 01:27:14
On Wed, Sep 17, 2014 at 10:08 AM, Gleb Natapov wrote:
> On Wed, Sep 17, 2014 at 10:00:32AM -0700, Andres Lagar-Cavilla wrote:
>> On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov wrote:
>> > On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
>> >> 2014-09-17 13:26+0300, Gleb Natapov:
>> >>
On Wed, Sep 17, 2014 at 10:00:32AM -0700, Andres Lagar-Cavilla wrote:
> On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov wrote:
> > On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
> >> 2014-09-17 13:26+0300, Gleb Natapov:
> >> > For async_pf_execute() you do not need to even retry. Next
On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov wrote:
> On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
>> 2014-09-17 13:26+0300, Gleb Natapov:
>> > For async_pf_execute() you do not need to even retry. Next guest's page
>> > fault
>> > will retry it for you.
>>
>> Wouldn't that be a
On Wed, Sep 17, 2014 at 12:43 AM, Paolo Bonzini wrote:
> Il 16/09/2014 20:42, Andres Lagar-Cavilla ha scritto:
>> On Tue, Sep 16, 2014 at 11:29 AM, Paolo Bonzini wrote:
I think a first patch should introduce kvm_get_user_page_retry ("Retry
a
fault after a gup with FOLL_NOW
On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
> 2014-09-17 13:26+0300, Gleb Natapov:
> > For async_pf_execute() you do not need to even retry. Next guest's page
> > fault
> > will retry it for you.
>
> Wouldn't that be a waste of vmentries?
This is how it will work with or without
[Repost for lists, the last mail was eaten by a security troll.]
2014-09-16 14:01-0700, Andres Lagar-Cavilla:
> On Tue, Sep 16, 2014 at 1:51 PM, Radim Krčmář
> wrote:
> > 2014-09-15 13:11-0700, Andres Lagar-Cavilla:
> >> +int kvm_get_user_page_retry(struct task_struct *tsk, struct
> >> mm_struct
2014-09-17 13:26+0300, Gleb Natapov:
> For async_pf_execute() you do not need to even retry. Next guest's page fault
> will retry it for you.
Wouldn't that be a waste of vmentries?
The guest might be able to handle interrupts while we are waiting, so if
we used async-io-done notifier, this could
On Mon, Sep 15, 2014 at 01:11:25PM -0700, Andres Lagar-Cavilla wrote:
> When KVM handles a tdp fault it uses FOLL_NOWAIT. If the guest memory has been
> swapped out or is behind a filemap, this will trigger async readahead and
> return immediately. The rationale is that KVM will kick back the guest
Il 16/09/2014 20:42, Andres Lagar-Cavilla ha scritto:
> On Tue, Sep 16, 2014 at 11:29 AM, Paolo Bonzini wrote:
>>> I think a first patch should introduce kvm_get_user_page_retry ("Retry a
>>> fault after a gup with FOLL_NOWAIT.") and the second would add
>>> FOLL_TRIED ("This properly
On Tue, Sep 16, 2014 at 3:34 PM, Radim Krčmář wrote:
> [Emergency posting to fix the tag and couldn't find unmangled Cc list,
> so some recipients were dropped, sorry. (I guess you are glad though).]
>
> 2014-09-16 14:01-0700, Andres Lagar-Cavilla:
>> On Tue, Sep 16, 2014 at 1:51 PM, Radim Krčmá
[Emergency posting to fix the tag and couldn't find unmangled Cc list,
so some recipients were dropped, sorry. (I guess you are glad though).]
2014-09-16 14:01-0700, Andres Lagar-Cavilla:
> On Tue, Sep 16, 2014 at 1:51 PM, Radim Krčmář wrote:
> > 2014-09-15 13:11-0700, Andres Lagar-Cavilla:
> >
On Tue, Sep 16, 2014 at 1:51 PM, Radim Krčmář wrote:
> 2014-09-15 13:11-0700, Andres Lagar-Cavilla:
>> +int kvm_get_user_page_retry(struct task_struct *tsk, struct mm_struct *mm,
>
> The suffix '_retry' is not best suited for this.
> On first reading, I imagined we will be retrying something from
2014-09-15 13:11-0700, Andres Lagar-Cavilla:
> +int kvm_get_user_page_retry(struct task_struct *tsk, struct mm_struct *mm,
The suffix '_retry' is not best suited for this.
On first reading, I imagined we will be retrying something from before,
possibly calling it in a loop, but we are actually doi
On Tue, Sep 16, 2014 at 11:29 AM, Paolo Bonzini wrote:
> Il 16/09/2014 18:52, Andres Lagar-Cavilla ha scritto:
>> Was this:
>>
>> down_read(&mm->mmap_sem);
>> npages = get_user_pages(NULL, mm, addr, 1, 1, 0, NULL, NULL);
>> up_read(&mm->mmap_sem);
>>
>> the intention rather
Il 16/09/2014 18:52, Andres Lagar-Cavilla ha scritto:
> Was this:
>
> down_read(&mm->mmap_sem);
> npages = get_user_pages(NULL, mm, addr, 1, 1, 0, NULL, NULL);
> up_read(&mm->mmap_sem);
>
> the intention rather than get_user_pages_fast?
I meant the intention of the origin
On Tue, Sep 16, 2014 at 9:52 AM, Andres Lagar-Cavilla
wrote:
Apologies to all. Resend as lists rejected my gmail-formatted version.
Now on plain text. Won't happen again.
> On Tue, Sep 16, 2014 at 6:51 AM, Paolo Bonzini wrote:
>>
>> Il 15/09/2014 22:11, Andres Lagar-Cavilla ha scritto:
>> > +
Il 15/09/2014 22:11, Andres Lagar-Cavilla ha scritto:
> + if (!locked) {
> + BUG_ON(npages != -EBUSY);
VM_BUG_ON perhaps?
> @@ -1177,9 +1210,15 @@ static int hva_to_pfn_slow(unsigned long addr, bool
> *async, bool write_fault,
> npages = get_user_page_nowait(current
When KVM handles a tdp fault it uses FOLL_NOWAIT. If the guest memory has been
swapped out or is behind a filemap, this will trigger async readahead and
return immediately. The rationale is that KVM will kick back the guest with an
"async page fault" and allow for some other guest process to take o
21 matches
Mail list logo
