From: Lorenzo Stoakes <lstoakes@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH 0/2] Refactor do_fault_around()
Date: Fri, 17 Mar 2023 23:48:17 +0000 [thread overview]
Message-ID: <98fc8545-6bd3-4c06-9b12-d781a19982ac@lucifer.local> (raw)
In-Reply-To: <20230317163936.06d9c7d032a5c2296075caa1@linux-foundation.org>
On Fri, Mar 17, 2023 at 04:39:36PM -0700, Andrew Morton wrote:
> On Fri, 17 Mar 2023 21:58:24 +0000 Lorenzo Stoakes <lstoakes@gmail.com> wrote:
>
> > Refactor do_fault_around() to avoid bitwise tricks and arather difficult to
> > follow logic. Additionally, prefer fault_around_pages to
> > fault_around_bytes as the operations are performed at a base page
> > granularity.
> >
> > I have run this code against a small program I wrote which generates
> > significant input data and compares output with the original function to
> > ensure that it behaves the same as the old code across varying vmf, vma and
> > fault_around_pages inputs.
>
> Well, what changes were you looking for in that testing?
That there was no functional change between this refactoring and the existing
logic.
> do_fault_around() could become a no-op and most tests wouldn't notice.
> What we'd be looking for to test these changes is performance
> differences.
>
> Perhaps one could add a tracepoint to do_fault_around()'s call to
> ->map_pages, check that the before-and-after traces are identical.
>
>
> Or, if you're old school and lazy,
>
> if (!strcmp(current->comm, "name-of-my-test-program"))
> printk("name-of-my-test-program: %lu %lu\n",
> start_pgoff, end_pgoff)
>
> then grep-n-diff the dmesg output.
I am both old school and lazy, however I went so far as to literally copy/paste
the existing code and my speculative change to a userland program, generate a
whole host of random sensible input data and compare output data with this and
the original logic en masse.
This function is actually quite nice for testability as the input and output
variables are limited in scope, vmf->address, vmf->pgoff, vmf->vma->vm_start/end
+ vmf->vma->vm_pgoff and output start_pgoff, end_pgoff.
I could attach said program but it's some quite iffy C++ code that might horrify
small children and adults alike...
I am more than happy to do performance testing to see if there is any impact if
you require?
next prev parent reply other threads:[~2023-03-17 23:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 21:58 Lorenzo Stoakes
2023-03-17 21:58 ` [PATCH 1/2] mm: refactor do_fault_around() Lorenzo Stoakes
2023-03-17 21:58 ` [PATCH 2/2] mm: pefer fault_around_pages to fault_around_bytes Lorenzo Stoakes
2023-03-17 23:39 ` [PATCH 0/2] Refactor do_fault_around() Andrew Morton
2023-03-17 23:48 ` Lorenzo Stoakes [this message]
2023-03-17 23:59 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98fc8545-6bd3-4c06-9b12-d781a19982ac@lucifer.local \
--to=lstoakes@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox