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 560A8C4345F for ; Fri, 19 Apr 2024 14:57:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A70F46B0083; Fri, 19 Apr 2024 10:57:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A1F496B0085; Fri, 19 Apr 2024 10:57:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90DDC6B0087; Fri, 19 Apr 2024 10:57:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 71E306B0083 for ; Fri, 19 Apr 2024 10:57:26 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 15B3A1201FC for ; Fri, 19 Apr 2024 14:57:26 +0000 (UTC) X-FDA: 82026584892.20.43EBC9E Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf02.hostedemail.com (Postfix) with ESMTP id 2212A80012 for ; Fri, 19 Apr 2024 14:57:23 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=L5lovCCp; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713538644; 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=anU0O+Cl/8esjZTwZGOybpvL5bNXBFd1hgsJ4evVImA=; b=XmxQw0Lxt8nr4gXrRF+dYyLryvScJmJkATi0n2qwuwNtIgts/XetdKZJlFnthaO8uh6f1z LZiT3f9A2Iyi1PiCWxSLKfzi4dXHDYm0OgPnyEOlmuPpDM93Mc45zGyjwa3SZZDjfonDXp gzAgZrPSXYnjAs6R0xGrGgOg/s/TAlg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713538644; a=rsa-sha256; cv=none; b=3JrDxp+6/tJO0JIM6jG3RWFjzRJNC5ViFU/rm0qAoh2mU1kFzdskGiTpJzTM2XLH93vtfG YtAis9fkegfGwNkn2tKy9F2WRihBbZV64YnsraNFKp4YaolyPtFDlTF25axFkLR9OHZrr6 2bG2favEHSK6LzwbU8r8OXlDtN4vYTU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=L5lovCCp; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-de45d4ca525so2169751276.0 for ; Fri, 19 Apr 2024 07:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713538643; x=1714143443; 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=anU0O+Cl/8esjZTwZGOybpvL5bNXBFd1hgsJ4evVImA=; b=L5lovCCpcgEAVgPUTIMrndG8xPRChaH7tKCEfhNc9pW+DTYPubL9vHzQnz1TOORIx/ Dqhn3KowqxhUUx9AD0+96s2lgaJgPkQZCAWyCnVfkPxVI1BrTRKQJIS27HuNuAEH3t9h oOSaa+u4AvhwjMJDoK6Ez4hsh4TGDVpGSHLimukLC6MMBtvD0Fj/AN+OV96H6kE1AmF7 /2wq+CcxWBMxntrAbcK6BkJSzF2xQUi8/kciqa7f9C8UbFxHA91UYii2vpDTN9rwzYRq UY0xxu2A6YN39VxId4Nmw320CDk48OcPuVCyGVWji4CPwQDckOybjzm5sSg9NSCUss4N ujoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713538643; x=1714143443; 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=anU0O+Cl/8esjZTwZGOybpvL5bNXBFd1hgsJ4evVImA=; b=AO+ZorsEFo1+GoZmbxBW4kHnHcMRNaWgbupokM33keteJLYk5kbOGNRFh39Zac8A2I nZDBwz9SpMMVoX4ZkjbthU1t7bl5U2pXxqawL4gc0OIhdS7CAXkqaBJkl7go53zBot9V nnbe+hJf2z1rqwy3iBF1bZlRUILEKSJF+181T+NghpdhhWfC6cP/9Vr7quNvrR5HE5Co zFzyxEzvtZJr66qeDt9XmXd/BoSqg6KEYMLpo/mLlc+0bP5WXES2Tc2eBHyFETCbcsx8 zM4f+qaxL8fwh9ct3Xpi102nqvdfAsK0XxbsMZekjGW0HSejE5WKBI6SRWXzXRvVk/zJ 2uFA== X-Forwarded-Encrypted: i=1; AJvYcCWUHWI3PPmmjGY9tQT658LlCVezDjRpT7rESy/gbGqCpXySVG6pKColBuzTFXkJaH45LQFgmaqvMz2ZntIuPlB+oBo= X-Gm-Message-State: AOJu0YzetELCK0KrfUOUbWy8q22PkNXdGwutYIyJSR44hZgov9BLE6OF rvOASHpbHsFVg8BLG71gnBsT1+3ueTWU0NUYmtv9WMDyQxoECK3rh/5jxaQH5D/fI86lzsjGWUW MzlrPXwFoy+givBQnDFGqzRmc2U4yLVOyQuyw X-Google-Smtp-Source: AGHT+IF7adSkE8wdnmiPyn4mVpG1NnzdXX/L7t8LedIMavDd8o7JUrBILI8u9VoVAMm7bza+xIeN6iKCZv+uvX8mkfQ= X-Received: by 2002:a25:2f87:0:b0:dc6:57d0:ac9 with SMTP id v129-20020a252f87000000b00dc657d00ac9mr2225865ybv.6.1713538642865; Fri, 19 Apr 2024 07:57:22 -0700 (PDT) MIME-Version: 1.0 References: <20240415163527.626541-1-jeffxu@chromium.org> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 19 Apr 2024 07:57:08 -0700 Message-ID: Subject: Re: [PATCH v10 0/5] Introduce mseal To: Jeff Xu Cc: "Liam R. Howlett" , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, corbet@lwn.net, merimus@google.com, rdunlap@infradead.org, jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org, deraadt@openbsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 2212A80012 X-Stat-Signature: qzmxys335q11yitqzfu7ry6rdoghguss X-Rspam-User: X-HE-Tag: 1713538643-938348 X-HE-Meta: U2FsdGVkX1/SrXIThGfMUH7jOqJWd/ejOnWO6+t5aM6pMA+FsXhN6BG6ZoV/Ele1DZwqmE+7SXFxKUyxXjXzCdZwJIl5Xp3/xUi6PMMn66VnKKZtXAZEhaskVHsbBKkZ0jpxjw0+YPCOmXA0wRTQfd8qXA5L/qW1TgDSJSkMiGXVWBQyZirmdd2zbktdmROWVqDWLW1EBAGKoDy2sondLQNQwIlYVl0IQmiXt9vQPz3zk4L9Lx+a5H71enWifxtl/k+H01bEMKqF2kI2t00gvtJE3vwj1zUysJ3hjseliykvCsMcU5VDeNiFv2UeJEGVxWKAtSU5UNfOWu//TCRGBmYKX65ZpPQvIudVqXKcvFBoGikTNPEp0ZJFT8+qcuYjH2YRmV0Lvlc292JlD5eGvpG7wjZavo1eO4ybs6ZJdLd5IRTbz/Z5A5710AlBsFhU+57jiDlMZewa6iKkkSPWlPloXcn78K2Y3PuXKafZUkcO2c0nnEFE14yI+WjlmTIIjF5E8A/wWZx5hya0nVJpiSG5w9s++tWpQRmWJUzSFJV/k8uq//+NqsNWAymuXythAUHEerZk5PKm/W99hnK/cqVq6q89sqmfrwYnAQtklVD+euVIRZRW2qkZmD9IZMVsTDZrIHOSTsIUlIw+bZSE+8VIRB64ajuCIRSeqArT9oQnC8GC00kRTlwja/qEd5fUjDmlqqBDm4G/WQ8lWutHboZCBXZrEDLtq6JQKeBoRHOaT8tNBq/Alt2di9viTtXtn+Qbj4wmKYxqAwYy90zN85dmLSJkbCIgpQFqaewn+IEEIvm9apQBY073MCzU+cUGhafEy78zQOsijyyS57XXl9N5nXszN0PtMZKzvr6q7hly30CfiFz9FS37JMc1+eEM/btKywm9Sr8z4KIK4VvVQKFphyvbVGVphUxGSP6lqzxllYBsOyjFjPi20e9VcDStF73xuvKLsoJOjXSZEL1 nRESm33y kh9Ck42QtyWF7gO6JNMQVQyqWtmPqE3+l6Q/Mgf1hvmD7Nd7FovI54KEux8qaqO8is3MvnMfQmm71xvnCtQubhux9EwUpCY9SzqXhbTf95ZNtrcLgqpZ+1hjdjBf+MnYompeS6WOSJUgKThusgI2anENOuFE732flP/yISvTeiJXyldeXRXwWGpiS35IqIzgDFRf/7rTIPT6GAhytpzOmfXy7p+XBnoXr/wBfOI6AnKr0wvoR237vCpLQMbDSUk3ri1qJdExAp/QCr1HjsAIECuJE2DQ++199ez0wEvBfXSMOHpy/Ky5ukfALt4+1t9GU0Ry+H5sqMm0z3Yl17ec/HRIyevKP5ChwsSESJgs7CZYfyHWQmsvgbaTWvJYvxh3vad5BEiSM+mwqEfY53HhjtZJJug== 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: On Thu, Apr 18, 2024 at 6:22=E2=80=AFPM Jeff Xu wrote= : > > On Thu, Apr 18, 2024 at 1:19=E2=80=AFPM Suren Baghdasaryan wrote: > > > > On Tue, Apr 16, 2024 at 12:40=E2=80=AFPM Jeff Xu = wrote: > > > > > > On Tue, Apr 16, 2024 at 8:13=E2=80=AFAM Liam R. Howlett wrote: > > > > > > > > * jeffxu@chromium.org [240415 12:35]: > > > > > From: Jeff Xu > > > > > > > > > > This is V10 version, it rebases v9 patch to 6.9.rc3. > > > > > We also applied and tested mseal() in chrome and chromebook. > > > > > > > > > > -----------------------------------------------------------------= - > > > > ... > > > > > > > > > MM perf benchmarks > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > This patch adds a loop in the mprotect/munmap/madvise(DONTNEED) t= o > > > > > check the VMAs=E2=80=99 sealing flag, so that no partial update c= an be made, > > > > > when any segment within the given memory range is sealed. > > > > > > > > > > To measure the performance impact of this loop, two tests are dev= eloped. > > > > > [8] > > > > > > > > > > The first is measuring the time taken for a particular system cal= l, > > > > > by using clock_gettime(CLOCK_MONOTONIC). The second is using > > > > > PERF_COUNT_HW_REF_CPU_CYCLES (exclude user space). Both tests hav= e > > > > > similar results. > > > > > > > > > > The tests have roughly below sequence: > > > > > for (i =3D 0; i < 1000, i++) > > > > > create 1000 mappings (1 page per VMA) > > > > > start the sampling > > > > > for (j =3D 0; j < 1000, j++) > > > > > mprotect one mapping > > > > > stop and save the sample > > > > > delete 1000 mappings > > > > > calculates all samples. > > > > > > > > > > > > Thank you for doing this performance testing. > > > > > > > > > > > > > > Below tests are performed on Intel(R) Pentium(R) Gold 7505 @ 2.00= GHz, > > > > > 4G memory, Chromebook. > > > > > > > > > > Based on the latest upstream code: > > > > > The first test (measuring time) > > > > > syscall__ vmas t t_mseal delta_ns per_vma % > > > > > munmap__ 1 909 944 35 35 104% > > > > > munmap__ 2 1398 1502 104 52 107% > > > > > munmap__ 4 2444 2594 149 37 106% > > > > > munmap__ 8 4029 4323 293 37 107% > > > > > munmap__ 16 6647 6935 288 18 104% > > > > > munmap__ 32 11811 12398 587 18 105% > > > > > mprotect 1 439 465 26 26 106% > > > > > mprotect 2 1659 1745 86 43 105% > > > > > mprotect 4 3747 3889 142 36 104% > > > > > mprotect 8 6755 6969 215 27 103% > > > > > mprotect 16 13748 14144 396 25 103% > > > > > mprotect 32 27827 28969 1142 36 104% > > > > > madvise_ 1 240 262 22 22 109% > > > > > madvise_ 2 366 442 76 38 121% > > > > > madvise_ 4 623 751 128 32 121% > > > > > madvise_ 8 1110 1324 215 27 119% > > > > > madvise_ 16 2127 2451 324 20 115% > > > > > madvise_ 32 4109 4642 534 17 113% > > > > > > > > > > The second test (measuring cpu cycle) > > > > > syscall__ vmas cpu cmseal delta_cpu per_vma % > > > > > munmap__ 1 1790 1890 100 100 106% > > > > > munmap__ 2 2819 3033 214 107 108% > > > > > munmap__ 4 4959 5271 312 78 106% > > > > > munmap__ 8 8262 8745 483 60 106% > > > > > munmap__ 16 13099 14116 1017 64 108% > > > > > munmap__ 32 23221 24785 1565 49 107% > > > > > mprotect 1 906 967 62 62 107% > > > > > mprotect 2 3019 3203 184 92 106% > > > > > mprotect 4 6149 6569 420 105 107% > > > > > mprotect 8 9978 10524 545 68 105% > > > > > mprotect 16 20448 21427 979 61 105% > > > > > mprotect 32 40972 42935 1963 61 105% > > > > > madvise_ 1 434 497 63 63 115% > > > > > madvise_ 2 752 899 147 74 120% > > > > > madvise_ 4 1313 1513 200 50 115% > > > > > madvise_ 8 2271 2627 356 44 116% > > > > > madvise_ 16 4312 4883 571 36 113% > > > > > madvise_ 32 8376 9319 943 29 111% > > > > > > > > > > > > > If I am reading this right, madvise() is affected more than the oth= er > > > > calls? Is that expected or do we need to have a closer look? > > > > > > > The madvise() has a bigger percentage (per_vma %), but it also has a > > > smaller base value (cpu). > > > > Sorry, it's unclear to me what the "vmas" column denotes. Is that how > > many VMAs were created before timing the syscall? If so, then 32 is > > the max that you show here while you seem to have tested with 1000 > > VMAs. What is the overhead with 1000 VMAs? > > The vmas column is the number of VMA used in one call. > > For example: for 32 and mprotect(ptr,size), the memory range used in > mprotect has 32 VMAs. Ok, so the 32 here denotes how many VMAs one mprotect() call spans? > > It also matters how many memory ranges are in-use at the time of the > test, This is where 1000 comes in. The test creates 1000 memory > ranges, each memory range has 32 vmas, then calls mprotect on the 1000 > memory range. (the pseudocode was included in the original email) So, if each range has 32 vmas and you have 1000 ranges then you are creating 32000 vmas? Sorry, your pseudocode does not clarify that. My current understanding is this: for (i =3D 0; i < 1000, i++) mmap N*1000 areas (N=3D[1-32]) start the sampling for (j =3D 0; j < 1000, j++) mprotect N areas with one syscall stop and save the sample munmap N*1000 areas calculates all samples. Is that correct? > > > My worry is that if the overhead grows linearly with the number of > > VMAs then the effects will be quite noticeable on Android where an > > application with a few thousand VMAs is not so unusual. > > > The overhead is likely to grow linearly with the number of VMA, since > it takes time to retrieve VMA's metadata. > > Let's use one data sample to look at impact: > > Test: munmap 1000 memory range, each memory range has 1 VMA > > syscall__ vmas t t_mseal delta_ns per_vma % > munmap__ 1 909 944 35 35 104% > > For those 1000 munmap calls, sealing adds 35000 ns in total, or 35 ns per= call. > > The delta seems to be insignificant. e.g. it will take about 28571 > munmap call to have 1 ms difference (1000000/35=3D28571) > > When I look at the data from 5.10 to 6.8, for the same munmap call, > 6.8 adds 552 ns per call, which is 15 times bigger. > > syscall__ vmas t_5_10 t_6_8 delta_ns per_vma % > munmap__ 1 357 909 552 552 254% I'm not yet claiming the overhead is too high. I want to understand first what is being measured here. Thanks, Suren. > > > > > > > > -Jeff