Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 27 Nov 2020 13:28:52 -0500
From:   Peter Xu <peterx@redhat.com>
To:     David Hildenbrand <david@redhat.com>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Hugh Dickins <hughd@google.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: Re: [PATCH] mm: Don't fault around userfaultfd-registered regions on
 reads
Message-ID: <20201127182852.GD6573@xz-x1>
References: <20201126222359.8120-1-peterx@redhat.com>
 <a240da04-1446-9282-c250-00507b745744@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <a240da04-1446-9282-c250-00507b745744@redhat.com>
Precedence: bulk

On Fri, Nov 27, 2020 at 06:00:44PM +0100, David Hildenbrand wrote:
> On 26.11.20 23:23, 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 best candidate for
> > pre-faults around the reads.
> 
> Are we getting uffd faults even though no-one actually accessed it?

Userfaultfd should only notify if someone accessed it.

> So in case I would track what some part of my program actually reads, I
> would get wrong notifications?

For shmem, we can't track it right now, afaict.  The message will only generate
if the page cache is not there.

While tracking page reads without page cache is helpless.. because they're all
zeros.

Thanks,

-- 
Peter Xu