On Fri, Aug 26, 2022 at 08:09:28AM +1000, Alistair Popple wrote:
> > I looked at some of the callers, it seems not all of them are ready to
> > handle that (__kvmppc_svm_page_out() or svm_migrate_vma_to_vram()). Is it
> > safe? Do the callers need to always properly handle that (unless the
> > mi
Peter Xu writes:
> On Thu, Aug 25, 2022 at 11:24:03AM +1000, Alistair Popple wrote:
>> By the way it's still an optimisation because in most cases we can avoid
>> calling try_to_migrate() and walking the rmap altogether if we install
>> the migration entries here. But I agree the comment is mis
On Thu, Aug 25, 2022 at 11:24:03AM +1000, Alistair Popple wrote:
> By the way it's still an optimisation because in most cases we can avoid
> calling try_to_migrate() and walking the rmap altogether if we install
> the migration entries here. But I agree the comment is misleading.
There's one foll
On Thu, Aug 25, 2022 at 10:42:41AM +1000, Alistair Popple wrote:
>
> Peter Xu writes:
>
> > On Wed, Aug 24, 2022 at 04:25:44PM -0400, Peter Xu wrote:
> >> On Wed, Aug 24, 2022 at 11:56:25AM +1000, Alistair Popple wrote:
> >> > >> Still I don't know whether there'll be any side effect of having
Alistair Popple writes:
> Peter Xu writes:
>>> But it's kind of against a pure "optimization" in that if trylock failed,
>>> we'll clear the mpfn so the src[i] will be zero at last. Then will we
>>> directly give up on this page, or will we try to lock_page() again
>>> somewhere?
>
> That co
Peter Xu writes:
> On Wed, Aug 24, 2022 at 04:25:44PM -0400, Peter Xu wrote:
>> On Wed, Aug 24, 2022 at 11:56:25AM +1000, Alistair Popple wrote:
>> > >> Still I don't know whether there'll be any side effect of having stall
>> > >> tlbs
>> > >> in !present ptes because I'm not familiar enough
On Wed, Aug 24, 2022 at 04:25:44PM -0400, Peter Xu wrote:
> On Wed, Aug 24, 2022 at 11:56:25AM +1000, Alistair Popple wrote:
> > >> Still I don't know whether there'll be any side effect of having stall
> > >> tlbs
> > >> in !present ptes because I'm not familiar enough with the private dev
> > >
On Wed, Aug 24, 2022 at 11:56:25AM +1000, Alistair Popple wrote:
> >> Still I don't know whether there'll be any side effect of having stall tlbs
> >> in !present ptes because I'm not familiar enough with the private dev swap
> >> migration code. But I think having them will be safe, even if redun
"Huang, Ying" writes:
> Peter Xu writes:
>
>> On Thu, Aug 18, 2022 at 02:34:45PM +0800, Huang, Ying wrote:
>>> > In this specific case, the only way to do safe tlb batching in my mind is:
>>> >
>>> > pte_offset_map_lock();
>>> > arch_enter_lazy_mmu_mode();
>>> > // If any pending t
Peter Xu writes:
> On Thu, Aug 18, 2022 at 02:34:45PM +0800, Huang, Ying wrote:
>> > In this specific case, the only way to do safe tlb batching in my mind is:
>> >
>> >pte_offset_map_lock();
>> >arch_enter_lazy_mmu_mode();
>> > // If any pending tlb, do it now
>> > if (mm
On Thu, Aug 18, 2022 at 02:34:45PM +0800, Huang, Ying wrote:
> > In this specific case, the only way to do safe tlb batching in my mind is:
> >
> > pte_offset_map_lock();
> > arch_enter_lazy_mmu_mode();
> > // If any pending tlb, do it now
> > if (mm_tlb_flush_pending())
> >
Peter Xu writes:
> On Wed, Aug 17, 2022 at 02:41:19AM -0700, Nadav Amit wrote:
>> 4. Having multiple TLB flushing infrastructures makes all of these
>> discussions very complicated and unmaintainable. I need to convince myself
>> in every occasion (including this one) whether calls to
>> flush_tl
Nadav Amit writes:
> On Aug 17, 2022, at 12:17 AM, Huang, Ying wrote:
>
>> Alistair Popple writes:
>>
>>> Peter Xu writes:
>>>
On Wed, Aug 17, 2022 at 11:49:03AM +1000, Alistair Popple wrote:
> Peter Xu writes:
>
>> On Tue, Aug 16, 2022 at 04:10:29PM +0800, huang ying wrot
On Wed, Aug 17, 2022 at 02:41:19AM -0700, Nadav Amit wrote:
> 4. Having multiple TLB flushing infrastructures makes all of these
> discussions very complicated and unmaintainable. I need to convince myself
> in every occasion (including this one) whether calls to
> flush_tlb_batched_pending() and t
On Wed, Aug 17, 2022 at 03:41:16PM +1000, Alistair Popple wrote:
> My primary concern with batching is ensuring a CPU write after clearing
> a clean PTE but before flushing the TLB does the "right thing" (ie. faults
> if the PTE is not present).
Fair enough. Exactly I have that same concern. But
On Aug 17, 2022, at 12:17 AM, Huang, Ying wrote:
> Alistair Popple writes:
>
>> Peter Xu writes:
>>
>>> On Wed, Aug 17, 2022 at 11:49:03AM +1000, Alistair Popple wrote:
Peter Xu writes:
> On Tue, Aug 16, 2022 at 04:10:29PM +0800, huang ying wrote:
>>> @@ -193,11 +194,10 @@
Alistair Popple writes:
> Peter Xu writes:
>
>> On Wed, Aug 17, 2022 at 11:49:03AM +1000, Alistair Popple wrote:
>>>
>>> Peter Xu writes:
>>>
>>> > On Tue, Aug 16, 2022 at 04:10:29PM +0800, huang ying wrote:
>>> >> > @@ -193,11 +194,10 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>>> >> >
Peter Xu writes:
> On Wed, Aug 17, 2022 at 11:49:03AM +1000, Alistair Popple wrote:
>>
>> Peter Xu writes:
>>
>> > On Tue, Aug 16, 2022 at 04:10:29PM +0800, huang ying wrote:
>> >> > @@ -193,11 +194,10 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>> >> > bool anon
On Wed, Aug 17, 2022 at 11:49:03AM +1000, Alistair Popple wrote:
>
> Peter Xu writes:
>
> > On Tue, Aug 16, 2022 at 04:10:29PM +0800, huang ying wrote:
> >> > @@ -193,11 +194,10 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> >> > bool anon_exclusive;
> >> >
Peter Xu writes:
> On Tue, Aug 16, 2022 at 04:10:29PM +0800, huang ying wrote:
>> > @@ -193,11 +194,10 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>> > bool anon_exclusive;
>> > pte_t swp_pte;
>> >
>> > + flush_cache_p
huang ying writes:
> On Tue, Aug 16, 2022 at 3:39 PM Alistair Popple wrote:
>>
>> migrate_vma_setup() has a fast path in migrate_vma_collect_pmd() that
>> installs migration entries directly if it can lock the migrating page.
>> When removing a dirty pte the dirty bit is supposed to be carried
On Tue, Aug 16, 2022 at 04:10:29PM +0800, huang ying wrote:
> > @@ -193,11 +194,10 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> > bool anon_exclusive;
> > pte_t swp_pte;
> >
> > + flush_cache_page(vma, addr, pte_pfn(*ptep
On Tue, Aug 16, 2022 at 3:39 PM Alistair Popple wrote:
>
> migrate_vma_setup() has a fast path in migrate_vma_collect_pmd() that
> installs migration entries directly if it can lock the migrating page.
> When removing a dirty pte the dirty bit is supposed to be carried over
> to the underlying pag
migrate_vma_setup() has a fast path in migrate_vma_collect_pmd() that
installs migration entries directly if it can lock the migrating page.
When removing a dirty pte the dirty bit is supposed to be carried over
to the underlying page to prevent it being lost.
Currently migrate_vma_*() can only be
24 matches
Mail list logo
