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 17D8FC52D7D for ; Fri, 16 Aug 2024 02:59:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 883148D0035; Thu, 15 Aug 2024 22:59:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 833338D002B; Thu, 15 Aug 2024 22:59:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D4218D0035; Thu, 15 Aug 2024 22:59:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4C74E8D002B for ; Thu, 15 Aug 2024 22:59:41 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BB97FA920E for ; Fri, 16 Aug 2024 02:59:40 +0000 (UTC) X-FDA: 82456603320.28.EA57257 Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf25.hostedemail.com (Postfix) with ESMTP id D3874A0003 for ; Fri, 16 Aug 2024 02:59:38 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=i9d0yeBy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of jeffxu@google.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723777165; a=rsa-sha256; cv=none; b=nEOlnKLJVcOm380OBYxDHDyWwRG+rifaITri6MzS2COHVLg51nrsZ5zNpFdwE4d1GsThSr g80ELTEQidZQKLYIVPeJFs9irG0WztVyKDLpUflgOUJYRQ56W1Cg+o0v70ZRxSYH/PC46m FT8HRlpT5zR+bjI1gW8hEtDwQtsQ3Ic= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=i9d0yeBy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of jeffxu@google.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723777165; 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=dRAxn9udby9Ekvy/JHFcZ+oOinR59nIxNeFf8Orxanw=; b=iByIyQIif1uuQgBTlOOmdosqPE3Z+Mld6w4zhKC4gJzWKYJlvep7zq6s94Ps4hymbsSh1m UmCb2QT1+7MgeIlM50SloSwcvLGu6L1hZziKobBMB/YU6SjYsTeCu3hPvgd9xJw4noDJTg bjIJW6cUXjGY05hiZpcBarcsPHHpX0I= Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-52efce25f36so397e87.1 for ; Thu, 15 Aug 2024 19:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723777177; x=1724381977; 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=dRAxn9udby9Ekvy/JHFcZ+oOinR59nIxNeFf8Orxanw=; b=i9d0yeByE1qWRiLdPEEy+rJY5giNxfZaZ6+kO8huPXVAs7QfcRgbGr9EqbEcdAvkBm QfpdHLQZdj6OBLdbDtVZO9jkihbHpOOLVcTOPguAMeZB8rmnOoIDR5WATGLiJ6k7WA7q B5oruHK8oPVPIMELu0TCbrjDqlC+Bu7+AEAb7KMNgqDrFj1AbyYYXrIMSub/RqO+rdB2 Ik2V7ds+o+X5Xw1ggpZnWjUqESuJnU1uLE7U/eNhgI3JQPF1IUZhB8FGCTJ3vYyAmeuQ 2zU3H8GK+fLEg5DH6tF1FWzhNHtdGTY90WdgN8za7BEpkobqVNxgndr3r+3U8XDPQjIH kCtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723777177; x=1724381977; 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=dRAxn9udby9Ekvy/JHFcZ+oOinR59nIxNeFf8Orxanw=; b=lujsuz/9/7xZ58F0mo4fvVSe2xD8FLZemxqFlG2vMUdVVIFe4QIeNo1bgInBeNoe/6 QQbJaqxhsZNV19Nu1PTo8u3usKohGv36w8bCPqPQpnHuhoLweRSrcFhUdonVWgPVY0BR 7KewNxA12zaIh8MCuz0YwiPjAg9AxCQ4Ib+YtyZlB0dTYMr3AAJl3ItZQLa+SplLOc88 s+j0yzZQ8DYKYJFiDqtyG/ZG2IXkGqovZwm/fEUyY+gelQ6Vh5csFtzNPOnjZOFPEGJI r3OosdRkGLYDOBwboZEB+z9/bfkid9z/Qvz7NcDmgVDbIpk3JuUQQNanku7Sj/RJ9SZX zrIw== X-Forwarded-Encrypted: i=1; AJvYcCVY4vax0EgRyFduCQdwwY7Is/Ugtb3TQWVrjp3WYI1Am30fDq5DYGEcijIFc1ucGoeC8HRzS8/bhLNTea2c0ufn4Io= X-Gm-Message-State: AOJu0Yy6LkyM2Sq1NyMZsRRPOG4FTnnFhOZz+M1T/a4v0PX1UuU6NEeL X9OlC63jGO6+T8f2eWoCuq39N0sjB0hh4avqFojMJCzSNd7+vM6g4AeJEROd5q5zCLA0MeU1IoK BUgMfrOq+lnF08LsWRABCJFbdX+e0TAAv3tRI X-Google-Smtp-Source: AGHT+IFMi/6G2XsQqWJDVUCZfW2i6sTX4SSy604sCDsTUe0V3lq0tzEHuMILXCOVPEhBFl5gbtv/dUm6XIBdPaWbnBY= X-Received: by 2002:a05:6512:39c5:b0:530:c2ef:db2c with SMTP id 2adb3069b0e04-5331ca481e8mr40488e87.2.1723777176519; Thu, 15 Aug 2024 19:59:36 -0700 (PDT) MIME-Version: 1.0 References: <20240814071424.2655666-1-jeffxu@chromium.org> In-Reply-To: From: Jeff Xu Date: Thu, 15 Aug 2024 19:58:57 -0700 Message-ID: Subject: Re: [PATCH v1 0/2] mremap refactor: check src address for vma boundaries first. To: Oliver Sang Cc: Jeff Xu , akpm@linux-foundation.org, willy@infradead.org, torvalds@linux-foundation.org, Liam.Howlett@oracle.com, pedro.falcato@gmail.com, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, lorenzo.stoakes@oracle.com, mpe@ellerman.id.au, vbabka@suse.cz, keescook@chromium.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: D3874A0003 X-Rspamd-Server: rspam01 X-Stat-Signature: sos6qbtfrhzsg4srndknuwp5qbsx7ns5 X-HE-Tag: 1723777178-570083 X-HE-Meta: U2FsdGVkX18alBjOwktYzYmleCNdmN0miXi/hd6HIDS72RMU0trBymsDXdw5vbjEEPP3cu5n8N3CgcH75sKTEMPjldwVxD9+r8b9k00fgyGpRTYJCk8w/iYY1FcHkE10bumcfygxyruhLl+CN+QTsGYJxqqXdLKRavJTN8NZ3BWsajVwTh1J18cdRV4zMV2BKkPmtd8a4uooG7/ZxNwIjOfxcE6z/UQrXKVAd3frkvHEJVxPqA3ac94j+P3BTPfRphuqYuwX/UtMo0OMkzZWB0PP+yqH/GgLFhhppOOidR3bAbWuRTPxrVdOsaYxWjyYzm1wPD91ptQ7qQQ568jNY55B53Xm18QNfz4IEgwKYod2W1GnflQ3/tqtqpEypr0NGcG2cBojC7QPk9e+uaoYX/eKk0f36RmDZMkq0aKB+h9PnAOf5YL8mJhyuhgSPiKRCbPQQvHklwuCNX53OeEsNKMZP2vuLag/8COlovLfgOxjhTXoR9hS2UnGFf8p0sZ8h0R7NPYGnNYGe6nogZBytjlmuw6b2/oIBdNhxd66PtuR66VPiONa/K7z08VhI3+uFBdmrqYbA7So7en0tJ2JZ2/B27eRPXbzr71l3IxLQkKv8E9tBM7WpFt+8j9Ds3w0dBw4kDcXXt2zB5euNOnJxNHhNCHlqsjCLbN0gtkS7ZCfW5Y8/c69NJB9sLuHJvDf0Wk4dsbgeYo/cijIxqo1UVHNT0QOTZO/Syn6UffxL86VI1MP9qAkPY2zagfPsFyroVmFKTlzByGTRUDpCIHmEWSPey0r/4hdQScxidY3mnw7bDOi9Bro13zhRSzuh3iblZydM0uxHmdCGVji9caJA5wiaL6MpkQkTwMujgeZLNiJ8p5qpj7wFcigrE5OGB87JBc1GWuaAO2pWC2MH6gALxlLs90EdZEeeXtThtexwBVo+22omwOsjyIZYUsYS7VdGyVLcHvmRdPrCgygMzJ frkqly9d GV6vB5zE1EKIbwagZsSBXSgcF4k3+lQb4knbpO1btNLn8MMWs/2IPVRzCnS0dZY2GeN1oHtdI6r5DbpIMS97lPHWD/ERHg/3Sat06YrDKcnXrNLvxJnY0r0BGapY2WrKsOmGy1yRCqQRHfHjQj26WVX8Ri89tNpgDv5oJhdaHf0vg9C55dBRSYnZLnSrFgK/NTyCAvZjOLJ7u/oEM0slzD1v0bFT5vAe98Hoi/8n4UMrhSSC25yyklFQuDNELk6CvXsfZ00cGBsG1qaRAc+kVJ+JmffYj/V+qTmvZO0BVV9W1LV4/+jJxQjLP7PkHsBj8Atj1Y/A0wrvTakSbHAlUwu16jGudhIqtybC0lsRwe02svYjcoUkB5k6rgxUlNcWVNaOvQqNM4tMWg04qoj93qiqh7Q== 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 7:39=E2=80=AFPM Oliver Sang = wrote: > > hi, Jeff, > > On Thu, Aug 15, 2024 at 01:19:06PM -0700, Jeff Xu wrote: > > Hi Oliver, > > > > On Thu, Aug 15, 2024 at 11:16=E2=80=AFAM Jeff Xu = wrote: > > > > > > 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, previousl= y > > > > the code does sealing check using can_modify_mm for the src address= range, > > > > 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 te= sts in > > > > mseal_test, the test patch can be applied before mremap refactor pa= tch or > > > > checkin independently. > > > > > > > > Also this patch doesn't change mseal's existing schematic: if seali= ng fail, > > > > user can expect the src/dst address isn't updated. So this patch ca= n be > > > > applied regardless if we decided to go with current out-of-loop app= roach > > > > 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 --= pagemove 64 > > > > > > > > I can't repro this using ChromeOS, the pagemove test shows large va= lue > > > > of stddev and stderr, and can't reasonably refect the performance i= mpact. > > > > > > > > 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 improvmen= t/impact > > > > 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 ru= ns with > > > > run_stress_ng 10 > > > > > > > > (I will run longer duration to see if test still shows large stdDev= ,StdErr) > > > > > > > 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, reboo= t > > > 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 tes= t. > > > > > 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 --page= move 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. > > what's the base of it? could I directly apply this patch upon the commit > what you said "after mseal feature" as below? > > > -> after mseal feature > > -> before mseal feature > > could you exlictly point to two commit-id? sure this patch 8be7258a: mseal: add mseal syscall ff388fe5c: mseal: wire up mseal syscall > > > > Thank you for your time and assistance in helping me on understanding > > this issue. > > due to resource constraint, please expect that we need several days to fi= nish > this test request. No problem. Thanks for your help! -Jeff > > > > Best regards, > > -Jeff > > > > > -Jeff > > > > > > > [1] https://lore.kernel.org/lkml/202408041602.caa0372-oliver.sang@i= ntel.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 > > > >