From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1992BC4727E for ; Thu, 1 Oct 2020 15:46:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7378520796 for ; Thu, 1 Oct 2020 15:46:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dT0cpPKG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7378520796 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 95A7F6B0070; Thu, 1 Oct 2020 11:46:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90AFE6B0071; Thu, 1 Oct 2020 11:46:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D11B6B0072; Thu, 1 Oct 2020 11:46:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id 4E05E6B0070 for ; Thu, 1 Oct 2020 11:46:21 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CE9FA181AE870 for ; Thu, 1 Oct 2020 15:46:20 +0000 (UTC) X-FDA: 77323783320.21.birth12_210ebd02719c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id A2FDC180442C3 for ; Thu, 1 Oct 2020 15:46:20 +0000 (UTC) X-HE-Tag: birth12_210ebd02719c X-Filterd-Recvd-Size: 12197 Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Thu, 1 Oct 2020 15:46:19 +0000 (UTC) Received: by mail-pf1-f195.google.com with SMTP id d6so4878749pfn.9 for ; Thu, 01 Oct 2020 08:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QW720dDg6w8WjYZQQLyUzFkTDggeR43z1zPv/IrMZ24=; b=dT0cpPKGpgzEScHP6GjGacfyG89UjBtM4nbWhLskXE8OBM+LpA3cfiIaQQzwNTfnh4 uWeC8lhol/0pNhI0i9kxVq5tjolCKWjKI2SwVKJZAA+dfYporGTzxFSp69fV3t89j4V8 LQN81t24F5+XcsoRXyJDNWQfPaCnlvqvP522Mu0dN951VwZuHg1PN6gtbt7rq1DKIo4T YskPmbBPJBLm/ql6UEeV9WaZF0qcH8F2y688w751qYuK9ARsSw579XDi0vFek3hG/91T m/4vD51knsCwY6pPeK/ury1qzq3med0bXP6YEo6+yzH4cHSI2kER7GqeEOlQYOw4Q+kY 9CBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QW720dDg6w8WjYZQQLyUzFkTDggeR43z1zPv/IrMZ24=; b=bSfJO0Pqk25/Ayd6SaCiNX+WQetPvH/iJk+DMohvqGaX1plmiNgz7SXtpUiz2bH72X mHj00in2rtEAl7rbpISb3VPhDjn7NvK55NvjWcl6xwSLFrp3QfTwt9U6sD1nRFAIpvNu rUbKDsO8adcXjgeih2TQUNWdyRaV3rqg18z1QBTg0kOzbf6ezGiWtFVTkOhE76y/H37p mg1YCs2BjceGcVb6FKFxQrBryZ/70+rkY6pHGCML5zWeSQjeZfvRl+U2q0UUJkNq96ZF 5SToY+IvPAePTNjo5ZKWudJgyNJF8ysME1plB7LTU4ORB1PxPiWvP2l/HDX/5tBebjZy U7KA== X-Gm-Message-State: AOAM532DJHjv0nMK6eXch40zqz1c66FGo36eOUW91nhwF6LcOA6NeSZn QXDCBk5m6MQZiBbEGGjZQ1Kku9OMZ8qc4aO14dU4JA== X-Google-Smtp-Source: ABdhPJwyo92ngttdaUJqIplWuz05ypEN5fgXAsM5QaNEs5Dyzgrhise69twwtOtjBiI/RFlHiC37e/EUKB9mlZBcVdM= X-Received: by 2002:a65:5cc2:: with SMTP id b2mr6663685pgt.124.1601567178571; Thu, 01 Oct 2020 08:46:18 -0700 (PDT) MIME-Version: 1.0 References: <20200930222130.4175584-1-kaleshsingh@google.com> <20200930222130.4175584-2-kaleshsingh@google.com> <0dc41856-e406-7f00-1eb9-5e97e476afa4@nvidia.com> In-Reply-To: <0dc41856-e406-7f00-1eb9-5e97e476afa4@nvidia.com> From: Kalesh Singh Date: Thu, 1 Oct 2020 11:46:07 -0400 Message-ID: Subject: Re: [PATCH 1/5] kselftests: vm: Add mremap tests To: John Hubbard Cc: Suren Baghdasaryan , Minchan Kim , Joel Fernandes , Lokesh Gidra , "Cc: Android Kernel" , Catalin Marinas , Will Deacon , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "the arch/x86 maintainers" , "H. Peter Anvin" , Andrew Morton , Shuah Khan , "Aneesh Kumar K.V" , Kees Cook , Peter Zijlstra , Sami Tolvanen , Arnd Bergmann , Masahiro Yamada , Frederic Weisbecker , Krzysztof Kozlowski , Hassan Naveed , Christian Brauner , Mark Rutland , Mike Rapoport , Gavin Shan , Dave Martin , Jia He , Zhenyu Ye , Jason Gunthorpe , Zi Yan , Mina Almasry , "Kirill A. Shutemov" , Ram Pai , Sandipan Das , Dave Hansen , Ralph Campbell , Brian Geffon , Masami Hiramatsu , Ira Weiny , SeongJae Park , LKML , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , "open list:MEMORY MANAGEMENT" , "open list:KERNEL SELFTEST FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 1, 2020 at 3:24 AM John Hubbard wrote: > > On 9/30/20 3:21 PM, Kalesh Singh wrote: > > Test mremap on regions of various sizes and alignments and validate > > data after remapping. Also provide total time for remapping > > the region which is useful for performance comparison of the mremap > > optimizations that move pages at the PMD/PUD levels if HAVE_MOVE_PMD > > and/or HAVE_MOVE_PUD are enabled. > > > > Signed-off-by: Kalesh Singh > > --- > > tools/testing/selftests/vm/.gitignore | 1 + > > tools/testing/selftests/vm/Makefile | 1 + > > tools/testing/selftests/vm/mremap_test.c | 243 ++++++++++++++++++++++= + > > tools/testing/selftests/vm/run_vmtests | 11 + > > 4 files changed, 256 insertions(+) > > create mode 100644 tools/testing/selftests/vm/mremap_test.c > > > > Hi, > > This takes 100x longer to run than it should: 1:46 min of running time on > my x86_64 test machine. The entire selftests/vm test suite takes 45 sec o= n a > bad day, where a bad day is defined as up until about tomorrow, when I wi= ll > post a compaction_test.c patch that will cut that time down to about half= , or > 24 sec total run time...for 22 tests! > > In other words, most tests here should take about 1 or 2 seconds, unless = they > are exceptionally special snowflakes. > > At the very least, the invocation within run_vmtests could pass in a para= meter > to tell it to run a shorter test. But there's also opportunities to speed= it > up, too. Hi John. Thanks for the comments. The bulk of the test time comes from setting and verifying the byte pattern in 1GB or larger regions for testing the HAVE_MOVE_PUD functionality. Without test= ing 1GB or larger regions the test takes 0.18 seconds on my x86_64 system. One option I think would be to only validate to a certain threshold of the = remap region. We can have a flag to specify a threshold or to validate the full size of the remapped region. I did some initial testing with a 4MB threshold and the total time dropped to 0.38 seconds from 1:12 minutes (for verifying the entire remapped region). The 4MB threshold would cover the full region of all the tests excluding those for the 1GB and 2GB sized regions. Let me know what you think. Your other comments below sound good to me. I=E2=80=99ll make those changes= in the next version. Thanks, Kalesh > > ... > > + > > +#define MAKE_TEST(source_align, destination_align, size, \ > > + overlaps, should_fail, test_name) \ > > +{ \ > > + .name =3D test_name, \ > > + .config =3D { \ > > + .src_alignment =3D source_align, \ > > + .dest_alignment =3D destination_align, \ > > + .region_size =3D size, \ > > + .overlapping =3D overlaps, \ > > + }, \ > > + .expect_failure =3D should_fail \ > > +} > > + > > OK... > > > +#define MAKE_SIMPLE_TEST(source_align, destination_align, size) \ > > + MAKE_TEST(source_align, destination_align, size, 0, 0, \ > > + #size " mremap - Source " #source_align \ > > + " aligned, Destination " #destination_align \ > > + " aligned") > > + > > ...and not OK. :) Because this is just obscuring things. Both the > code and the output are harder to read. For these tiny test programs, > clarity is what we want, not necessarily compactness on the screen. > Because people want to get in, understand what they seen in the code > and match it up with what is printed to stdout--without spending much > time. (And that includes run time, as hinted at above.) > > ... > > + > > +/* Returns the time taken for the remap on success else returns -1. */ > > +static long long remap_region(struct config c) > > +{ > > + void *addr, *src_addr, *dest_addr; > > + int i, j; > > + struct timespec t_start =3D {0, 0}, t_end =3D {0, 0}; > > + long long start_ns, end_ns, align_mask, ret, offset; > > + char pattern[] =3D {0xa8, 0xcd, 0xfe}; > > I'd recommend using rand() to help choose the pattern, and using differen= t > patterns for different runs. When testing memory, it's a pitfall to have > the same test pattern. > > Normally, you'd also want to report the random seed or the test pattern(s= ) > or both to stdout, and provide a way to run with the same pattern, but > here I don't *think* you care: all patterns should have the same performa= nce. > > > + int pattern_size =3D ARRAY_SIZE(pattern); > > + > > + src_addr =3D get_source_mapping(c); > > + if (!src_addr) { > > + ret =3D -1; > > + goto out; > > + } > > + > > + /* Set byte pattern */ > > + for (i =3D 0; i < c.region_size; i++) { > > + for (j =3D 0; i+j < c.region_size && j < pattern_size; j+= +) > > + memset((char *) src_addr + i+j, pattern[j], 1); > > + i +=3D pattern_size-1; > > + } > > + > > + align_mask =3D ~(c.dest_alignment - 1); > > + offset =3D (c.overlapping) ? -c.dest_alignment : c.dest_alignment= ; > > A comment for what the above two lines are doing would be a nice touch. > > ... > > + start_ns =3D t_start.tv_sec * 1000000000ULL + t_start.tv_nsec; > > + end_ns =3D t_end.tv_sec * 1000000000ULL + t_end.tv_nsec; > > A const or #defined for all those 0000's would help. > > ... > > +int main(int argc, char *argv[]) > > +{ > > + int failures =3D 0; > > + int i; > > + > > + struct test test_cases[] =3D { > > + /* Expected mremap failures */ > > + MAKE_TEST(_4KB, _4KB, _4KB, 1 /* overlaps */, 1 /* fails = */, > > Named flags instead of 1's and 0's would avoid the need for messy comment= s. > > > + "mremap - Source and Destination Regions Overla= pping"), > > + MAKE_TEST(_4KB, _1KB, _4KB, 0 /* overlaps */, 1 /* fails = */, > > + "mremap - Destination Address Misaligned (1KB-a= ligned)"), > > + MAKE_TEST(_1KB, _4KB, _4KB, 0 /* overlaps */, 1 /* fails = */, > > + "mremap - Source Address Misaligned (1KB-aligne= d)"), > > + > > + /* Src addr PTE aligned */ > > + MAKE_SIMPLE_TEST(PTE, PTE, _8KB), > > + > > + /* Src addr 1MB aligned */ > > + MAKE_SIMPLE_TEST(_1MB, PTE, _2MB), > > + MAKE_SIMPLE_TEST(_1MB, _1MB, _2MB), > > + > > + /* Src addr PMD aligned */ > > + MAKE_SIMPLE_TEST(PMD, PTE, _4MB), > > + MAKE_SIMPLE_TEST(PMD, _1MB, _4MB), > > + MAKE_SIMPLE_TEST(PMD, PMD, _4MB), > > + > > + /* Src addr PUD aligned */ > > + MAKE_SIMPLE_TEST(PUD, PTE, _2GB), > > + MAKE_SIMPLE_TEST(PUD, _1MB, _2GB), > > + MAKE_SIMPLE_TEST(PUD, PMD, _2GB), > > + MAKE_SIMPLE_TEST(PUD, PUD, _2GB), > > > Too concise. Not fun lining these up with the stdout report. > > > thanks, > -- > John Hubbard > NVIDIA > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >