This patchset ensures that the number of hugepages is correctly set in the
system so that the uffd-stress test does not fail due to the racy nature of
the test. Patch 1 corrects the hugepage constraint in the run_vmtests.sh
script, whereas patch 2 corrects the constraint in the test itself.

Dev Jain (2):
  selftests/mm/uffd-stress: Make test operate on less hugetlb memory
  selftests/mm/uffd-stress: Stricten constraint on free hugepages before
    the test

 tools/testing/selftests/mm/run_vmtests.sh | 2 +-
 tools/testing/selftests/mm/uffd-stress.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.30.2

On 26/08/25 12:37 pm, Dev Jain wrote:
> This patchset ensures that the number of hugepages is correctly set in the
> system so that the uffd-stress test does not fail due to the racy nature of
> the test. Patch 1 corrects the hugepage constraint in the run_vmtests.sh
> script, whereas patch 2 corrects the constraint in the test itself.
>
> Dev Jain (2):
>    selftests/mm/uffd-stress: Make test operate on less hugetlb memory
>    selftests/mm/uffd-stress: Stricten constraint on free hugepages before
>      the test
>
>   tools/testing/selftests/mm/run_vmtests.sh | 2 +-
>   tools/testing/selftests/mm/uffd-stress.c  | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)

Hi Andrew,

I wanted to make a v2 of this series to replace 10 with min(32, nrcpus - 1)
(see computation of nr_parallel in uffd-stress.c) but I see that it has
been pulled into mm-new, and on top of that, the following patch makes
things complicated to just revert my commits in mm-new and make v2 on top of that -
https://lore.kernel.org/all/20250830033424.8C44FC4CEF0@smtp.kernel.org/

So shall I just send a new separate patch based off mm-new?

On Mon, 8 Sep 2025 13:52:05 +0530 Dev Jain <dev.jain@arm.com> wrote:

> 
> On 26/08/25 12:37 pm, Dev Jain wrote:
> > This patchset ensures that the number of hugepages is correctly set in the
> > system so that the uffd-stress test does not fail due to the racy nature of
> > the test. Patch 1 corrects the hugepage constraint in the run_vmtests.sh
> > script, whereas patch 2 corrects the constraint in the test itself.
> >
> > Dev Jain (2):
> >    selftests/mm/uffd-stress: Make test operate on less hugetlb memory
> >    selftests/mm/uffd-stress: Stricten constraint on free hugepages before
> >      the test
> >
> >   tools/testing/selftests/mm/run_vmtests.sh | 2 +-
> >   tools/testing/selftests/mm/uffd-stress.c  | 2 +-
> >   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> Hi Andrew,
> 
> I wanted to make a v2 of this series to replace 10 with min(32, nrcpus - 1)

That sounds line a one-line change?  Send a one-line change ;)

> (see computation of nr_parallel in uffd-stress.c) but I see that it has
> been pulled into mm-new, and on top of that, the following patch makes
> things complicated to just revert my commits in mm-new and make v2 on top of that -
> https://lore.kernel.org/all/20250830033424.8C44FC4CEF0@smtp.kernel.org/
> 
> So shall I just send a new separate patch based off mm-new?

Or just resend the whole series based on mainline or something?

On 09/09/25 7:32 am, Andrew Morton wrote:
> On Mon, 8 Sep 2025 13:52:05 +0530 Dev Jain <dev.jain@arm.com> wrote:
>
>> On 26/08/25 12:37 pm, Dev Jain wrote:
>>> This patchset ensures that the number of hugepages is correctly set in the
>>> system so that the uffd-stress test does not fail due to the racy nature of
>>> the test. Patch 1 corrects the hugepage constraint in the run_vmtests.sh
>>> script, whereas patch 2 corrects the constraint in the test itself.
>>>
>>> Dev Jain (2):
>>>     selftests/mm/uffd-stress: Make test operate on less hugetlb memory
>>>     selftests/mm/uffd-stress: Stricten constraint on free hugepages before
>>>       the test
>>>
>>>    tools/testing/selftests/mm/run_vmtests.sh | 2 +-
>>>    tools/testing/selftests/mm/uffd-stress.c  | 2 +-
>>>    2 files changed, 2 insertions(+), 2 deletions(-)
>> Hi Andrew,
>>
>> I wanted to make a v2 of this series to replace 10 with min(32, nrcpus - 1)
> That sounds line a one-line change?  Send a one-line change ;)
>
>> (see computation of nr_parallel in uffd-stress.c) but I see that it has
>> been pulled into mm-new, and on top of that, the following patch makes
>> things complicated to just revert my commits in mm-new and make v2 on top of that -
>> https://lore.kernel.org/all/20250830033424.8C44FC4CEF0@smtp.kernel.org/
>>
>> So shall I just send a new separate patch based off mm-new?
> Or just resend the whole series based on mainline or something?

I'll do this, since the change will be more than a line. Thanks.