On Fri, Dec 04, 2020 at 02:37:17PM -0500, Andrea Arcangeli wrote:
> If we use _UFFD_SWP_UFFD_WP it looks much cleaner to keep it in the
> pte, not in the swp entry, since then you can use the already existing
> methods that only can take in input the pte_t (not the swp_entry_t).
Ah, I see now. Ye
On Fri, Dec 04, 2020 at 02:23:29PM -0500, Peter Xu wrote:
> If we see [1]:
>
> if (!pte_present && !pte_none && pte_swp_uffd_wp && not_anonymous_vma &&
> !is_migration_entry)
>
> Then it's fundamentally the same as:
>
> swp_entry(0, _UFFD_SWP_UFFD_WP) && !vma_is_anonymous(vma)
Yes conceptu
Hi, Andrea,
On Fri, Dec 04, 2020 at 01:12:56PM -0500, Andrea Arcangeli wrote:
> On Thu, Dec 03, 2020 at 11:10:18PM -0500, Andrea Arcangeli wrote:
> > from the pte, one that cannot ever be set in any swp entry today. I
> > assume it can't be _PAGE_SWP_UFFD_WP since that already can be set but
> > y
On Thu, Dec 03, 2020 at 11:10:18PM -0500, Andrea Arcangeli wrote:
> from the pte, one that cannot ever be set in any swp entry today. I
> assume it can't be _PAGE_SWP_UFFD_WP since that already can be set but
> you may want to verify it...
I thought more about the above, and I think the already ex
On Thu, Dec 03, 2020 at 09:59:50PM -0800, Hugh Dickins wrote:
> On Thu, 3 Dec 2020, Andrea Arcangeli wrote:
> > On Thu, Dec 03, 2020 at 09:30:51PM -0500, Peter Xu wrote:
> > > I'm just afraid there's no space left for a migration entry, because
> > > migration
> > > entries fills in the pfn inform
On Thu, 3 Dec 2020, Andrea Arcangeli wrote:
> On Thu, Dec 03, 2020 at 09:30:51PM -0500, Peter Xu wrote:
> > I'm just afraid there's no space left for a migration entry, because
> > migration
> > entries fills in the pfn information into swp offset field rather than a
> > real
> > offset (please r
Hi Peter,
On Thu, Dec 03, 2020 at 09:30:51PM -0500, Peter Xu wrote:
> I'm just afraid there's no space left for a migration entry, because migration
> entries fills in the pfn information into swp offset field rather than a real
> offset (please refer to make_migration_entry())? I assume PFN can
On Thu, Dec 03, 2020 at 02:44:14PM -0500, Andrea Arcangeli wrote:
> On Thu, Dec 03, 2020 at 01:02:34PM -0500, Peter Xu wrote:
> > On Wed, Dec 02, 2020 at 09:36:45PM -0800, Hugh Dickins wrote:
> > > On Wed, 2 Dec 2020, Peter Xu wrote:
> > > > On Wed, Dec 02, 2020 at 02:37:33PM -0800, Hugh Dickins wr
On Thu, Dec 03, 2020 at 01:02:34PM -0500, Peter Xu wrote:
> On Wed, Dec 02, 2020 at 09:36:45PM -0800, Hugh Dickins wrote:
> > On Wed, 2 Dec 2020, Peter Xu wrote:
> > > On Wed, Dec 02, 2020 at 02:37:33PM -0800, Hugh Dickins wrote:
> > > > On Tue, 1 Dec 2020, Andrea Arcangeli wrote:
> > > > >
> > >
On Wed, Dec 02, 2020 at 09:36:45PM -0800, Hugh Dickins wrote:
> On Wed, 2 Dec 2020, Peter Xu wrote:
> > On Wed, Dec 02, 2020 at 02:37:33PM -0800, Hugh Dickins wrote:
> > > On Tue, 1 Dec 2020, Andrea Arcangeli wrote:
> > > >
> > > > Any suggestions on how to have the per-vaddr per-mm _PAGE_UFFD_WP
On Wed, 2 Dec 2020, Peter Xu wrote:
> On Wed, Dec 02, 2020 at 02:37:33PM -0800, Hugh Dickins wrote:
> > On Tue, 1 Dec 2020, Andrea Arcangeli wrote:
> > >
> > > Any suggestions on how to have the per-vaddr per-mm _PAGE_UFFD_WP bit
> > > survive the pte invalidates in a way that remains associated t
On Wed, Dec 02, 2020 at 02:37:33PM -0800, Hugh Dickins wrote:
> On Tue, 1 Dec 2020, Andrea Arcangeli wrote:
> >
> > Any suggestions on how to have the per-vaddr per-mm _PAGE_UFFD_WP bit
> > survive the pte invalidates in a way that remains associated to a
> > certain vaddr in a single mm (so it ca
On Tue, 1 Dec 2020, Andrea Arcangeli wrote:
>
> Any suggestions on how to have the per-vaddr per-mm _PAGE_UFFD_WP bit
> survive the pte invalidates in a way that remains associated to a
> certain vaddr in a single mm (so it can shoot itself in the foot if it
> wants, but it can't interfere with al
On Tue, Dec 01, 2020 at 05:30:33PM -0500, Peter Xu wrote:
> On Tue, Dec 01, 2020 at 12:59:27PM +, Matthew Wilcox wrote:
> > On Mon, Nov 30, 2020 at 06:06:03PM -0500, Peter Xu wrote:
> > > Faulting around for reads are in most cases helpful for the performance
> > > so that
> > > continuous mem
On Tue, Dec 01, 2020 at 12:59:27PM +, Matthew Wilcox wrote:
> On Mon, Nov 30, 2020 at 06:06:03PM -0500, Peter Xu wrote:
> > Faulting around for reads are in most cases helpful for the performance so
> > that
> > continuous memory accesses may avoid another trip of page fault. However it
> > m
On Mon, Nov 30, 2020 at 06:06:03PM -0500, Peter Xu wrote:
> Faulting around for reads are in most cases helpful for the performance so
> that
> continuous memory accesses may avoid another trip of page fault. However it
> may not always work as expected.
>
> For example, userfaultfd registered r
On 01.12.20 00:06, Peter Xu wrote:
> Faulting around for reads are in most cases helpful for the performance so
> that
> continuous memory accesses may avoid another trip of page fault. However it
> may not always work as expected.
>
> For example, userfaultfd registered regions may not be the b
Faulting around for reads are in most cases helpful for the performance so that
continuous memory accesses may avoid another trip of page fault. However it
may not always work as expected.
For example, userfaultfd registered regions may not be the best candidate for
pre-faults around the reads.
18 matches
Mail list logo
