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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 291BDC52D7F for ; Thu, 15 Aug 2024 20:19:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 978956B024C; Thu, 15 Aug 2024 16:19:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 929096B024D; Thu, 15 Aug 2024 16:19:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F01C6B024E; Thu, 15 Aug 2024 16:19:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5BBA66B024C for ; Thu, 15 Aug 2024 16:19:21 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D895AA176A for ; Thu, 15 Aug 2024 20:19:20 +0000 (UTC) X-FDA: 82455594480.20.874AC36 Received: from mail-oa1-f52.google.com (mail-oa1-f52.google.com [209.85.160.52]) by imf08.hostedemail.com (Postfix) with ESMTP id 077FD16002E for ; Thu, 15 Aug 2024 20:19:18 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=F+oadSf9; spf=pass (imf08.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.52 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723753122; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rwwh+m11coKDQ807HOXz5WqEZXo+puG96j+/w4ULqco=; b=40hQ230HiAFKECJ9pgm3PjfmVVQbKSVrDC/CKlU3jB56HKns8tP1+cLBaxzXk17JRlJ6UA HRUZluqF8ePoytxcQydJpH1NDdmYkrDrQFiiOykvR3PkHhwZUSY13eMx/po7ceL1c0FSVi WNlJCj7Q0WhhQRKsT2qLGOHQSytjGRs= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=F+oadSf9; spf=pass (imf08.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.52 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723753122; a=rsa-sha256; cv=none; b=s0fRdPhftNCNJtXi3EvQpNn0w6iXJ7rWXw9/E4LL6ZrI3nelH3xkTSWVIScHVh9PJoLrUn UXLkSEHIgivmw1L0bS6eIwOObJX6Q4OEQwHm2/TI0unYp9a5CwUW/G3HoUPuJOopZSRvsi JFBYnFYQGB+k98idyhc2AFje4KqvN2s= Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-260fed6c380so994451fac.1 for ; Thu, 15 Aug 2024 13:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1723753158; x=1724357958; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rwwh+m11coKDQ807HOXz5WqEZXo+puG96j+/w4ULqco=; b=F+oadSf9d/+0SDWYw7CYBbFNVk167PlDUs7tuAaXHqz3ga+3hnbUPWJiJfHCMLJYQQ bymc/j6tAXh0Sjoqy5VERcDY1npjRKbN4K6m/1yTZdJ6VEDWQvNa/r7/WmBnlAKguRpy V6Zx4jKb8MxgPiA8ggsZDgMEAHkRURS/2orII= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723753158; x=1724357958; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rwwh+m11coKDQ807HOXz5WqEZXo+puG96j+/w4ULqco=; b=gpr5PR3AhhtFNUnbBcAiWb9l2Wd+cp/ssBKAufQadHcUmxh7PKDYAVM/Onj5fpIntY FzSxUkpdObDsIdeTdRRsJE02h2wVS6Lg0O3KNob9TBECkfxAabNs9Mg869Ve955EG5tg mXrs5VzsOt4BMgFWyBsA2WLTdD9gtJ6j/rYuYzDigCFQSpLzbMGK5jzHv0tRDy90fgrl W9iMEJ0+lEHg/WubvZ+YiHdbfySJTTKwHWz2f06vmnf6eEM48a4AnzmPzqZY+ew/pofG MWlVN+52g5Zx1ezSnH9oGpPjipgND3mhWQ0zOpGhuYOucQaMxOzF4OCw6Jqf4bbLilKl yzAQ== X-Forwarded-Encrypted: i=1; AJvYcCVz3cCIbNwaHErwMPlpjYk6pD19EZm9y0RLEaFxicy0tDAPwePILtwxp1KJMaU0k4DlP8UABPGn/2d2gaEwGOQCHbY= X-Gm-Message-State: AOJu0YxTbXG8Axrf7ZZj8NXicFrFjCB8WJ1Ifts8UrL9s4wnhBdEHd8O 9jqUxA33KHY41oCanPuy+NwHMXE0awaJSm1R3ofKVGFy3kkjjrCQ+WXRrYzUzUeVxvzt01xmjzO MhOvlbZR/d+eFVvnbUJKyJWoAqZz7rGgdzDY+ X-Google-Smtp-Source: AGHT+IFNZUYqv7nnkMo6SmetQnUTNabfc8VVktvAcev4smjCTJVffFUd4p8V3E9vbbtG9gJR0VoqONU46YFGJfKLqrw= X-Received: by 2002:a05:6871:521f:b0:268:9f88:18ef with SMTP id 586e51a60fabf-2701c380d75mr819022fac.13.1723753157780; Thu, 15 Aug 2024 13:19:17 -0700 (PDT) MIME-Version: 1.0 References: <20240814071424.2655666-1-jeffxu@chromium.org> In-Reply-To: From: Jeff Xu Date: Thu, 15 Aug 2024 13:19:06 -0700 Message-ID: Subject: Re: [PATCH v1 0/2] mremap refactor: check src address for vma boundaries first. To: akpm@linux-foundation.org, willy@infradead.org, torvalds@linux-foundation.org, Liam.Howlett@oracle.com, pedro.falcato@gmail.com Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, jeffxu@google.com, lorenzo.stoakes@oracle.com, mpe@ellerman.id.au, oliver.sang@intel.com, vbabka@suse.cz, keescook@chromium.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 077FD16002E X-Stat-Signature: n7ggg4aianhyun456gmgsed5ynad4muw X-HE-Tag: 1723753158-413730 X-HE-Meta: U2FsdGVkX180hPAQwpRVW0dKOd3BJR6f2Jo0wgpgzT8Ljd+WJj862T6HC/GGPDA1ZqCN7VyLgOcBoPfLYnVuaa2qpDpkVIFAmTK8eRSk1J3fIjHILvH4wDJKIergaP4lfiIQtdykxIJn5pziPXdvbAIINkAJ+OC1ofSNZXzzrfMjKzdlg2kjoEX38rm6TB3ulqnhiE93opLUoVp4Crm6iodFPe0Dy3HR9vt80Ubtbzk92M3IMGagvtHEnPS/icDGjc8VdCjAgHZxQqWrA982hOgtqdQy6Lw087P5Fl1WSXR/tWpmj5s+/KQvY7B05vavdeearvPr2Exr2l97h+Fv6jdOMHDBV/8oIGUG9eeaomg5CpvJtI0TvGRKdmTjruizbJPp9NO5QR3V/88bugeJTeklWSy5jrPhMUhYfe8LwoqXH2B9xc8vr97QkOhsC27ZfBQe778d5C5+rCnlxuKt4hYdtrumjdukHsmksbxhZaECvUSQZHTlia80Hy0fICQjsrhsQ8VoluZAzVBAv3TEloSZRnzVCgh4OA3XNnXKznOQyYBK8uJksQ9MzST6DyC2lrabbGaASBRaKmmNVuMyVcZ/ntnA5uaYTCElXnKyc5zhS8mYYYVZBKwlqI0J4SJ+KNmi0ZpD7urfh2mRa0v+FiPs2GRdJw5h7SJmmDpC63HKqwOh2LqQXzMiVbZw5fVjDhcBBMkjRwnzCClaiImeIWMQwhKSuapowQOzxDX39RZ3hBi+mIYdbbOkLy3xxc/LWAdQ9HYmUgGeOJ6b1PGXcwXyd9C+OTiQhJfa2DkglydvPUHQSF2upunnek+33gEYRciof8+cdK+x5MZ0jGhe+wq/BXj8o/rRjJMPXbI9iET7o1jJ5qU6ZVUwC83JD1m5kqT6alTjT8HlXJRm7CS/z/HUmD/jzT8nRfSMKm7KOo0MOoo4Gy/WWGA2EUfakvfEGbqTSGXLyDu9qIl1lTh 4SRNOnzW RVhCOJL5ZMvKuzveThJnqIe1556ejzL9qkM5PoRUu1CgT7c/vMIgYs9nowlLiUvHnba5JyuBdlSku/zYH90m9ky3itasqly5dQyKoKWUWEl9b8fdZ/uhcKu4MYqQk9uAIINr369klBfkNiw0DKY4VX0gy02HXbjYci4VHZ/wrWh3KTP/Biu7OdmJ5RVQ5r/2m0a+4ebi/kmqy8IdRR/VZ3SBbd+VIyFMgUprw6upFehEkhQiW1oFxr3yyFWJoAKVNdrPgqd6SBa6HM9qr7Q06rlakylcND4H6G/de3iMPStR3ydIY9cqwVDYfKFzqbXqCEj4n6AyaPVl8/ygNalNqGOubvbLTR65PZcAeRtbKFQXEZK4GanJa7Ek1QTzh+x3j91JL1b3z/+q1PnaHqmNL9MkpI+tEs+uAYimGEaZ/E9LtjVsDb5h2JGlBUjRkljaRRJfK 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: List-Subscribe: List-Unsubscribe: Hi Oliver, On Thu, Aug 15, 2024 at 11:16=E2=80=AFAM Jeff Xu wrot= e: > > On Wed, Aug 14, 2024 at 12:14=E2=80=AFAM wrote: > > > > From: Jeff Xu > > > > mremap doesn't allow relocate, expand, shrink across VMA boundaries, > > refactor the code to check src address range before doing anything on > > the destination, i.e. destination won't be unmapped, if src address > > failed the boundaries check. > > > > This also allows us to remove can_modify_mm from mremap.c, since > > the src address must be single VMA, can_modify_vma is used. > > > > It is likely this will improve the performance on mremap, previously > > the code does sealing check using can_modify_mm for the src address ran= ge, > > and the new code removed the loop (used by can_modify_mm). > > > > In order to verify this patch doesn't regress on mremap, I added tests = in > > mseal_test, the test patch can be applied before mremap refactor patch = or > > checkin independently. > > > > Also this patch doesn't change mseal's existing schematic: if sealing f= ail, > > user can expect the src/dst address isn't updated. So this patch can be > > applied regardless if we decided to go with current out-of-loop approac= h > > or in-loop approach currently in discussion. > > > > Regarding the perf test report by stress-ng [1] title: > > 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression > > > > The test is using below for testing: > > stress-ng --timeout 60 --times --verify --metrics --no-rand-seed --page= move 64 > > > > I can't repro this using ChromeOS, the pagemove test shows large value > > of stddev and stderr, and can't reasonably refect the performance impac= t. > > > > For example: I write a c program [2] to run the above pagemove test 10 = times > > and calculate the stddev, stderr, for 3 commits: > > > > 1> before mseal feature is added: > > Ops/sec: > > Mean : 3564.40 > > Std Dev : 2737.35 (76.80% of Mean) > > Std Err : 865.63 (24.29% of Mean) > > > > 2> after mseal feature is added: > > Ops/sec: > > Mean : 2703.84 > > Std Dev : 2085.13 (77.12% of Mean) > > Std Err : 659.38 (24.39% of Mean) > > > > 3> after current patch (mremap refactor) > > Ops/sec: > > Mean : 3603.67 > > Std Dev : 2422.22 (67.22% of Mean) > > Std Err : 765.97 (21.26% of Mean) > > > > The result shows 21%-24% stderr, this means whatever perf improvment/im= pact > > there might be won't be measured correctly by this test. > > > > This test machine has 32G memory, Intel(R) Celeron(R) 7305, 5 CPU. > > And I reboot the machine before each test, and take the first 10 runs w= ith > > run_stress_ng 10 > > > > (I will run longer duration to see if test still shows large stdDev,Std= Err) > > > I took more samples (100 run ), the stddev/stderr is smaller, however > still not at a range that can reasonably measure the perf improvement > here. > > The tests were taken using the same machine as (10 times run above) > and exact the same steps: i.e. change to certain kernel commit, reboot > test device, take the first test result. > > 1> Before mseal feature is added: > Statistics: > Ops/sec: > Mean : 1733.26 > Std Dev : 842.13 (48.59% of Mean) > Std Err : 84.21 (4.86% of Mean) > > 2> After mseal feature is added > Statistics: > Ops/sec: > Mean : 1701.53 > Std Dev : 1017.29 (59.79% of Mean) > Std Err : 101.73 (5.98% of Mean) > > 3> After mremap refactor (this patch) > Statistics: > Ops/sec: > Mean : 1097.04 > Std Dev : 860.67 (78.45% of Mean) > Std Err : 86.07 (7.85% of Mean) > > Summary: even when the stderr is down to 4%-%8 percentage range, the > stddev is still too big. > > Hence, there are other unknown, random variables that impact this test. > I could not repro the 4% degradation with my test machine (Chromebook), this can be entirely due to the specific test and this test machine. Do you think it is possible to do a few more tests ? This time I like to have a larger sample size (100 run) stress-ng --timeout 60 --times --verify --metrics --no-rand-seed --pagemove= 64 Please run the test for each commit following the exact steps, e.g. reboot the machine, run the test, get the first 100 results for sample. Please don't select or drop any unstable report because then the data will be biased. If possible, please includes stddiv and stderr for the data (or raw data if not possible, and I will do post-processing) for 3 commits: -> this patch. -> after mseal feature -> before mseal feature Thank you for your time and assistance in helping me on understanding this issue. Best regards, -Jeff > -Jeff > > > [1] https://lore.kernel.org/lkml/202408041602.caa0372-oliver.sang@intel= .com/ > > [2] https://github.com/peaktocreek/mmperf/blob/main/run_stress_ng.c > > > > > > Jeff Xu (2): > > mseal:selftest mremap across VMA boundaries. > > mseal: refactor mremap to remove can_modify_mm > > > > mm/internal.h | 24 ++ > > mm/mremap.c | 77 +++---- > > mm/mseal.c | 17 -- > > tools/testing/selftests/mm/mseal_test.c | 293 +++++++++++++++++++++++- > > 4 files changed, 353 insertions(+), 58 deletions(-) > > > > -- > > 2.46.0.76.ge559c4bf1a-goog > >