On Tue, 8 Oct 2019, Leonardo Bras wrote:
> So you say that the performance impact of using my approach is the same
> as using locks? (supposing that lock never waits)
>
> So, there are 'lockless pagetable walks' only for the sake of better
> performance?
I thought that was the major motivation
On Tue, 2019-10-08 at 17:43 +, Christopher Lameter wrote:
> On Tue, 8 Oct 2019, Leonardo Bras wrote:
>
> > > You are creating contention on a single exclusive cacheline. Doesnt this
> > > defeat the whole purpose of the lockless page table walk? Use mmap_sem or
> > > so should cause the same p
On Tue, 8 Oct 2019, Leonardo Bras wrote:
> > You are creating contention on a single exclusive cacheline. Doesnt this
> > defeat the whole purpose of the lockless page table walk? Use mmap_sem or
> > so should cause the same performance regression?
>
> Sorry, I did not understand that question.
>
On Tue, 2019-10-08 at 15:11 +, Christopher Lameter wrote:
>
> On Wed, 2 Oct 2019, Leonardo Bras wrote:
>
> > +
> > +inline unsigned long __begin_lockless_pgtbl_walk(struct mm_struct *mm,
> > +bool disable_irq)
> > +{
> > + unsigned long irq_mask =
On Wed, 2 Oct 2019, Leonardo Bras wrote:
> +
> +inline unsigned long __begin_lockless_pgtbl_walk(struct mm_struct *mm,
> + bool disable_irq)
> +{
> + unsigned long irq_mask = 0;
> +
> + if (IS_ENABLED(CONFIG_LOCKLESS_PAGE_TABLE_WALK_TRACKING)
It's necessary to monitor lockless pagetable walks, in order to avoid doing
THP splitting/collapsing during them.
On powerpc, we need to do some lockless pagetable walks from functions
that already have disabled interrupts, specially from real mode with
MSR[EE=0].
In these contexts, disabling/ena
