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 6E307C4345F for ; Fri, 19 Apr 2024 16:54:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D13E36B0096; Fri, 19 Apr 2024 12:54:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC3B06B009A; Fri, 19 Apr 2024 12:54:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8B026B009E; Fri, 19 Apr 2024 12:54:30 -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 95BA76B0096 for ; Fri, 19 Apr 2024 12:54:30 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3F9AD1A024D for ; Fri, 19 Apr 2024 16:54:30 +0000 (UTC) X-FDA: 82026879900.28.547301D Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf27.hostedemail.com (Postfix) with ESMTP id 7BA5B40007 for ; Fri, 19 Apr 2024 16:54:28 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xiVjCrye; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713545668; a=rsa-sha256; cv=none; b=d3eiOkDnn3w5OrhKrrLkzuVLsLuCTsFhUBPzHC0EXoDKWWhyVpJZDkGzXyK1QD/ym19OZ/ YP/VJ2HhZOn767BGeXspZEdGke4CrT9hHlee6+lNpLzZcc+l93MuDUwpv57mL8hx09flkS +BU2+gcz+wgecInJ4/UVwhF5sMyqG7M= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xiVjCrye; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.128.177 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=1713545668; 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=dBpoOyRi1gACy8UrMdPa5IxAxynbsn8XkxmG646b1Bc=; b=Z0FZxEChxeiQuNId7MJIOlJ3K/J5b8UtIswi/jYmrLla0jegYZsfypuvhYESnkE1AyUd+I xitfVjwwrifXg44047pzDA/QGkjdMDUu5up0oRbV/AfVO1bfG88QEb6b9FA2fB5aDUgLiv vEj0QeQ8r9YVuJYDNqwcjl387+3UhbE= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-617d25b2bc4so23325597b3.2 for ; Fri, 19 Apr 2024 09:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713545667; x=1714150467; 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=dBpoOyRi1gACy8UrMdPa5IxAxynbsn8XkxmG646b1Bc=; b=xiVjCryeUqoEJrb8pJfPsD2brgFm9z7MLgWYfppANQEuwHu/ArzelRfSPcglQatToi jg6ER/aH6JbhqmWIoNsV/SowoA9QNwLZPw3IKlUqCGAX59Kexl5Vf1DQsj0rfG9oxdmu 8pcAxuhJQX1DZeO8EMIsscOAZ1MTCvHC/QG73uo7IXpjbqdLfmb6Mtgk0T3Zx9/8dzSY 5z/aCGkrZ1P23IYQSpDlWUMInjXQqF1J2AOFzXvXbJdvK5nskdEYnQA1SbXMLpIOEvPV 3qGn3fCCTVA+Rmz9QjppLNzUxfN5vn7JuQnX3MT+u8VgL5xYHINE25eSUcpithN/c6/z rD6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713545667; x=1714150467; 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=dBpoOyRi1gACy8UrMdPa5IxAxynbsn8XkxmG646b1Bc=; b=ZKiPha31yEbLzlhFAN+3d/OtWt0txhAc6Mj+CkPcV5jTn2jtTel94mPN59WFVSPxRH /eZCRltAEPlI02YscSCGNTzgG43Iuv/sBPrzp0eHw6nTukAa5bQgx8LLUQkdkR93dflx MyX9HCVU0t1wniMNJ0s3q77/1jKLNU65JF6VVbqprj7OrERjNHMfhyGdGHYT7KJ9KvKp gECoNEHjCBIkjibkt8w4gY88bcJnV6bhlwFhPl/p50QzoQOM8wKgsd9RG5XU5hJgywiL eloI6yv78higw6Fg3uQe/IlPjF/cCgQFkXseAaKiDuLy6tTU/9csPWlq1Pj1oP9go829 OWDg== X-Forwarded-Encrypted: i=1; AJvYcCWcasXSDg0tAaaJXE+WxnzLtZZqlOJMD3ImfP68TkAWUQdR5lNXpNn/eL9xGwQedkEpGnWN4y2KBA87jt6oiKL5SC8= X-Gm-Message-State: AOJu0YxoOilhv1NUQ5AohSKyBdwS3hBa7PDZEXN21Xuj+LTsxIvahSYX +xl/QP/ySmqf0f+E/MqyblKFflqFvtCcFoDZWTczK7Xkl635gZ/uer2ggjV8oBkk1f4hfSASkg9 Scu0VbACu2AjdjA8DiwkJEdxqbelfw1+xxxK9 X-Google-Smtp-Source: AGHT+IFeGdiIWY6aOqpTE9Q8KjfPAJjPwyLn2RAn+sOxC4h2XiQHg/rVuol4OCtdU/LH0LByBkWiRetj/4daQ0VyqHM= X-Received: by 2002:a05:6902:218f:b0:dc6:aebb:168e with SMTP id dl15-20020a056902218f00b00dc6aebb168emr3117818ybb.26.1713545667251; Fri, 19 Apr 2024 09:54:27 -0700 (PDT) MIME-Version: 1.0 References: <20240415163527.626541-1-jeffxu@chromium.org> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 19 Apr 2024 16:54:13 +0000 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: rspam03 X-Rspamd-Queue-Id: 7BA5B40007 X-Stat-Signature: 9i3qnewmub3kwda7fubk4hry18ha9aq4 X-Rspam-User: X-HE-Tag: 1713545668-591165 X-HE-Meta: U2FsdGVkX19fsijWa0vSEIoA1IjC0MhEaxdK0fzOSFhQgOztn0KqxsyfV0/rID5+8kRNWe1AhanNBXAJM6gnDZJqG+EvNdVi+Km4UqHeQ2j/nyTRvPShzq1DVMLHgp7G7pGqfPn51kqZffuGED0WM2UTZdcmi+NbvhfOl91uHXJ90KVVXyVHuTTsZUvrK7n0hufKsmmUp9oYRND8Fhn5tUGC0wbPqEj0aFnKVolh3wUCnMzDVCa7bDZq0GseOBDF+OZ3E10Aey2LPKRukN01V95hE/F1SQm3mGWdgkpJiuupSOk1SNkSz/EEZRLQnACWjuAvsYYvaqLZYJZqI3FEWXTYMf87bmHIG6sY207bjiUBpNJcxe+nkNkQoVXXW4J5icpOvGkTU5CVU8j6LXOBH73b2OS1o9IaTRf8yaiiY1f5UnWXKCml6iQsXfipy0MPG68wtkt5u0H+HkGF1jVcJoqjy3F/hoVzPVR+8sTHvWMlj+8AkuBcYirNIP0nKzqbbt9Lefw7WzLXxm68IeDv8wvXqN8c3Gd3FhDD7cfTCqqH+rtWrNm2N/rCemTYQSPbNsZJJ1p1VBGZg9uia9tEGtQxgxtp7wvfU9pE7GJjiyCMddfJu7Z439QkScBYARZ9cAHdQqGogMSLXGt3PCdu4yQGtS2Y0AOvtDU61GyXO5ylBVXOSjJeO9G6BKqyrLo6JqNqk6Yh187dPHRAOqoIcJ0EqRirJMF8n9U4IyU9Dfg23Irncwlzde1uZfLNw9xGXmycs5XIUUxb3pMwDsHcupxovsQc4rXpFwgKtxUeu898YHRLOgWA30weeWm9oZjJGzpIWgACl/aIMOz5PVXeMVSr6OYurFkhLk6dybooCOmJy1hzpQWedEYtaYQs9o3wGdOWduOUShJVQao4bQi8LQ+3M9+5uiBRlcVGwNYDgxKyTKPYvtVAUnRPMs3f2LYhSSAar3P9pS3ydUkXQ5U wAgTN+RT npDEbb6b88pFEXiGKuizE9oxD/abvmkEQICstlf4sOCNH+KcSYCn9BhzneaZ8U+/OLc4Zk9WEuIxYTgGLeJtfyJLO/oUlMTMllOu8r93E1gx1TnUg9dRAAFLDVtoiiEzpUFolzcTJvEGqNKdCrnzkNI+H6UU90BVjDbxkwzlOCz+siqHdyH7GuYU4p0CiPAU9z+9kdJ5jAMibJPJkbPi1Et4vdDSPmMM6XBBwf10utBRNEmtzizD7OdAURrvxuk47a8ifPzPbfX8ujyYa5r0dRQ+EB8t78iTbfylt/Yvtih417WgUmHBMVSXQ/rAagiQ5Lvi98Ytqsl41/6oFCAPoyK8usbmMBvml7ilUrdvOTM0S/p71w6FeuQXieOlLCqI3raDcscmJKOkIBj4ViadX/VnWSg== 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 Fri, Apr 19, 2024 at 3:15=E2=80=AFPM Jeff Xu wrote= : > > On Fri, Apr 19, 2024 at 7:57=E2=80=AFAM Suren Baghdasaryan wrote: > > > > On Thu, Apr 18, 2024 at 6:22=E2=80=AFPM Jeff Xu w= rote: > > > > > > 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(DONTNEE= D) to > > > > > > > check the VMAs=E2=80=99 sealing flag, so that no partial upda= te can be made, > > > > > > > when any segment within the given memory range is sealed. > > > > > > > > > > > > > > To measure the performance impact of this loop, two tests are= developed. > > > > > > > [8] > > > > > > > > > > > > > > The first is measuring the time taken for a particular system= call, > > > > > > > by using clock_gettime(CLOCK_MONOTONIC). The second is using > > > > > > > PERF_COUNT_HW_REF_CPU_CYCLES (exclude user space). Both tests= have > > > > > > > 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.00GHz, > > > > > > > 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= other > > > > > > calls? Is that expected or do we need to have a closer look? > > > > > > > > > > > The madvise() has a bigger percentage (per_vma %), but it also ha= s a > > > > > smaller base value (cpu). > > > > > > > > Sorry, it's unclear to me what the "vmas" column denotes. Is that h= ow > > > > 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? > > > Yes. > > > > > > > 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 100= 0 > > > 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? > > > Yes, There will be 32000 VMA in the system. > > The pseudocode is correct in concept. > The test implementation is slightly different, it uses mprotect to > split the memory and make sure the VMAs doesn't merge. For detail, > the reference [8] of the original email link to the test code. Ok, thanks for clarifications. I don't think the overhead is high enough to worry about. Thanks, Suren. > > -Jeff