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 36EB3C52D7F for ; Thu, 15 Aug 2024 21:11:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD7A86B0259; Thu, 15 Aug 2024 17:11:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A87CD6B025A; Thu, 15 Aug 2024 17:11:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 977146B025B; Thu, 15 Aug 2024 17:11:29 -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 7A9986B0259 for ; Thu, 15 Aug 2024 17:11:29 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F394AA17B0 for ; Thu, 15 Aug 2024 21:11:28 +0000 (UTC) X-FDA: 82455725856.01.BFBF4DE Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) by imf02.hostedemail.com (Postfix) with ESMTP id 2050D80025 for ; Thu, 15 Aug 2024 21:11:26 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ISi5S5P3; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf02.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.51 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723756274; a=rsa-sha256; cv=none; b=nbYZM6p/LMSdt2D91RZZUkdEvyUDOkWg4JqS3B3L9lSV2fjps98S0p8X14lfvaBIMQAfWH HHvIiLtuVIU8EHq2LghU6oUaOvUvU+BfqWcmgd5Td0+vu1NJgbI4Voglyw1Jm/KSlg96Dy x0/b8GAxcD3dEPEQArpgz5YFiJmpNTU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ISi5S5P3; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf02.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.51 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723756274; 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=qdKF/gkZMwPX+H+11QhhQU4+WryLhYLHGOpnlPXdpLQ=; b=TejmD/Cmfbg3caafF+uDMkloguZCWdETJQ0JmsmVABNMIZWWK/6wJuJSv13C3WV4Fyd9uA WwWXTou8CA2Tr7GCQgR3+XQ86VNanmH2phjdMeZ6/g6Hw1QXMwh+kaEUS4y5zgNpwfPvSN wwKHYkzSH8N+yVw+VgF9UsaYaL/Bfl0= Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-260e6dfc701so947439fac.3 for ; Thu, 15 Aug 2024 14:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1723756286; x=1724361086; 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=qdKF/gkZMwPX+H+11QhhQU4+WryLhYLHGOpnlPXdpLQ=; b=ISi5S5P30xxj9z33GiqA7gD/Pw8n5ht49UBNL91TqwWLIEO4/5GwK+Zpze2Lu/iPCn HJNbJakgLBCrPlQ4ozJy7rExiC+oi2Pt6m/lr0TNvCxcaTSB5LGm1ZUx6nNrJZ9WQ0qP hqKaZ0DVjCR39S/udOWDerRc1O0dSpkVwZvUs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723756286; x=1724361086; 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=qdKF/gkZMwPX+H+11QhhQU4+WryLhYLHGOpnlPXdpLQ=; b=P9IjBUR+fCVCKdO18gGuZo06Vt0/BI4+LUttvz4hRArDVevmSSs4AX0MymWfASfGR7 jTApVVQl60TOW9y6l8kuTV3LWdvXhRgOqnSaAdefLhrimj+/9fDxjwgLfjNrR1ZcQskh bCALajnDCco1ATHwSN5SqiWiQXDn0Fd0q1TaHyadTNocPxqAGDW342IxSOKvqklw9GKd 2KuAygOsBuvGxyVZNhyyeI/HGPLeGvI1r74WympVtMa/OvUEU77SySpf3ipNkR6qwHvM IA8nTrrXYjgW3cXpu8efyoDaY3kTbjFawL3/DFQaXJRb9jNT5dskv5cTn0x6FLgKJNO6 w/pg== X-Forwarded-Encrypted: i=1; AJvYcCVksBO/2bBpmar3W4L8swsVQs4+Y4JawgOZBFXkypHwTGr6lEbXGXdOEmwmsrO9dIXakI440rC2Y+d11mjo7xED8EE= X-Gm-Message-State: AOJu0YwPhFU76fKP+4QS/AlM9Ehu+4p+ILxKZ3aV97kPtMWlZ6yn9XgT mH1g38IMLTCrPOsWvzp3CEYhGthJz4cAGBGdnF7DxyZWH/pCYtHaUE30YWVG63fTPhkiix/cgY4 kOoOrDIaYPzRTyXwj6jSkr/oYJZPfK6QqVHOLyOBLGPUuySLNQA== X-Google-Smtp-Source: AGHT+IFJOBm7a/M1FkC0dbPS9gMvxIVi6WTkmF36w+02qnIHiiF8/SEj3MkUTd6HNVqNIRqvot9m+KwRu2bsx92JY3I= X-Received: by 2002:a05:6870:a489:b0:268:acce:455f with SMTP id 586e51a60fabf-2701c519f8amr834141fac.32.1723756285989; Thu, 15 Aug 2024 14:11:25 -0700 (PDT) MIME-Version: 1.0 References: <20240807211309.2729719-1-pedro.falcato@gmail.com> In-Reply-To: <20240807211309.2729719-1-pedro.falcato@gmail.com> From: Jeff Xu Date: Thu, 15 Aug 2024 14:11:14 -0700 Message-ID: Subject: Re: [PATCH v2 0/6] mm: Optimize mseal checks To: Pedro Falcato Cc: Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, oliver.sang@intel.com, torvalds@linux-foundation.org, jeffxu@google.com, Michael Ellerman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 2050D80025 X-Rspamd-Server: rspam01 X-Stat-Signature: iju36zmat6978f6gpfkobrptayjcgj31 X-HE-Tag: 1723756286-815650 X-HE-Meta: U2FsdGVkX19tvqa2pHacbsZWfes7NB5R0na0KzPklOLDnd+7k407v0mVStRhaOvy28MtrvYZDfT8rJLxCBfjlFYmpLq2jkfgtwMpXIQjAT30yeNKpZjh+UOpb8qkZ3MiTNqpP+at1AjcUdVnlyQ4PNpSCKcFIGQqg25lkx+F5TqiSFDuUYWr3wYCfg/wFTvEQATjre9le6jVivVerWVrrtcfInaw7MNSlsmtS5SI0fllBctAJwFcUenDiILVO/xcOprExtAZYC6/7h0XoM79JBDpdK/oJH7jmUfb97yQXF/hpIT97+zJTiUQz9NexEFgYxeU1hNl9yEHCxLkYEZJ4KI3WUoMEoIWiKCoPKARoB/WNsKgLKzmRSWc1qV6oVl5oHOwFge3q0c+3hDUVxschllZp60JvWLOeDcbnxCrgl8XXO09mLpCeo5zb70C8lM0sGWled6AQiPsEvXjS6x6VVmYUVGlAw+8ztyM9Pgf3fHoxa6mNnsQmHBIqMMjQRHUN8TzOACjK2emoyuIz3aovXRzxputEqgKiL7pUQk19tmbchBQrLbjKkRRTHkB15srn+aUEnKAT6hbJHkdogSpBW/h9yetuM6GkH5sQk0C/s6sqGtn/X0nhCjJNgMKDd0yE7vxLKls0u8VUtOkUaRfcSCp8OABUNSh/ir+fqUFpJ7c1wctjplOKbKXxL81okeK2RZ1MTfIPiiZu53PM3HWTg64hEtoRpLpvGsRKJ1ahOkfIJY9EXf5X/deh0Fb1yxmcz+CNWuv2DGEYebch1oRqafY8VmfYiB2Dvo3QxYNL5Gp6Aw0FB5tBZktJdDIhRD/DE/MF6DtMymzrqBf7TWM+5w3hXbk47yf2P9P8o8gyDWMu2Ursg9qzkG5UifJUjjeuoc2VPL63nYI0lWhN5Eq9zOUtb+dNoH221pepq8bL5fjCU6VqkWFz6d7EkeE+s8GubIbA4xlBolCyM+YaCD KDiqVtOO NZdd8YiUTA1dyHZnTrxqtFu02aGn3BcY1mXFzzGgNDgj4j/oZIx6nbVgb5ZqxXd2XN1DOnHxhySKU8QpCwO0+Z0P0UvwqgzOT5M6RsgBsM/cizl3DLaYb6Bsbg6Eg0V6PzhcWYKL5ITaxi/L2nj60dEctcnLZU5o1LWzfg/5xcZOqJboU2uE5x6LYKTzz/uEzHFsQaG6MLc8a6mNeAHDhQKq8IrbPLh4rcrU8vLFcRmgm9MKlsteHV/trYkvUP7Nw/iZ626L74vJb7thhFsMoWrsCbe1vF1yJrIMF2oT4fbxa7bxXnnOZg0gKaIkdNsXQXpkaqM1R2Euq23IO8MNMnBCQXTvEmCjoGsX5l5AvNzHDqovAvClaharqF0ojLL7lXc0lIneEYLFHCm8rC11O+XwUYekqwNm7iwwf 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 Wed, Aug 7, 2024 at 2:13=E2=80=AFPM Pedro Falcato wrote: > > [based on mm-unstable, 98808d08] > > Optimize mseal checks by removing the separate can_modify_mm() step, and > just doing checks on the individual vmas, when various operations are > themselves iterating through the tree. This provides a nice speedup and r= estores > performance parity with pre-mseal[3]. > > This series also depends on (and will eventually very slightly conflict w= ith) > the powerpc series that removes arch_unmap[2]. > > will-it-scale mmap1_process[1] -t 1 results: > > commit 3450fe2b574b4345e4296ccae395149e1a357fee: > > min:277605 max:277605 total:277605 > min:281784 max:281784 total:281784 > min:277238 max:277238 total:277238 > min:281761 max:281761 total:281761 > min:274279 max:274279 total:274279 > min:254854 max:254854 total:254854 > measurement > min:269143 max:269143 total:269143 > min:270454 max:270454 total:270454 > min:243523 max:243523 total:243523 > min:251148 max:251148 total:251148 > min:209669 max:209669 total:209669 > min:190426 max:190426 total:190426 > min:231219 max:231219 total:231219 > min:275364 max:275364 total:275364 > min:266540 max:266540 total:266540 > min:242572 max:242572 total:242572 > min:284469 max:284469 total:284469 > min:278882 max:278882 total:278882 > min:283269 max:283269 total:283269 > min:281204 max:281204 total:281204 > > After this patch set: > > min:280580 max:280580 total:280580 > min:290514 max:290514 total:290514 > min:291006 max:291006 total:291006 > min:290352 max:290352 total:290352 > min:294582 max:294582 total:294582 > min:293075 max:293075 total:293075 > measurement > min:295613 max:295613 total:295613 > min:294070 max:294070 total:294070 > min:293193 max:293193 total:293193 > min:291631 max:291631 total:291631 > min:295278 max:295278 total:295278 > min:293782 max:293782 total:293782 > min:290361 max:290361 total:290361 > min:294517 max:294517 total:294517 > min:293750 max:293750 total:293750 > min:293572 max:293572 total:293572 > min:295239 max:295239 total:295239 > min:292932 max:292932 total:292932 > min:293319 max:293319 total:293319 > min:294954 max:294954 total:294954 > > This was a Completely Unscientific test but seems to show there were arou= nd 5-10% gains on ops per second. > It is likely true that the test " was Completely Unscientific". Without the necessary information, such as stddiv, stderr, and large enough sample size, it is impossible to prove the test can reasonably measure the impact of the patch. Unless you add that information, it would be prudent to omit this test data from the cover letter. > Oliver performed his own tests and showed[3] a similar ~5% gain in them. > > [1]: mmap1_process does mmap and munmap in a loop. I didn't bother testin= g multithreading cases. > [2]: https://lore.kernel.org/all/20240807124103.85644-1-mpe@ellerman.id.a= u/ > [3]: https://lore.kernel.org/all/ZrMMJfe9aXSWxJz6@xsang-OptiPlex-9020/ > Link: https://lore.kernel.org/all/202408041602.caa0372-oliver.sang@intel.= com/ > > Changes in v2: > - Rebased on top of mm-unstable > - Removed a superfluous check in mremap (Jeff Xu) Thanks for taking this suggestion. When I posted that comment, I was studying the mremap change in V2, I'm not 100% sure if it is possible, or reasonable the code is written that way (even before mseal is added.) This week, I wrote more self-tests [1] for the mremap to reason about the code handling of mremap across the VMA boundary, as part of an effort to test your patch. During the process I realized that we can probably improve the mremap code further, even without considering the sealing, so I made a refactor patch for mremap. [2]. Testing is 90% of the time, if not more, when I modify the kernel code. If you agree with my refactor on mremap, please feel free to rebase or include it as part of your patch series. Thanks -Jeff [1] https://lore.kernel.org/linux-mm/20240814071424.2655666-2-jeffxu@chromi= um.org/ [2] https://lore.kernel.org/linux-mm/20240814071424.2655666-3-jeffxu@chromi= um.org/ > Pedro Falcato (6): > mm: Move can_modify_vma to mm/internal.h > mm/munmap: Replace can_modify_mm with can_modify_vma > mm/mprotect: Replace can_modify_mm with can_modify_vma > mm/mremap: Replace can_modify_mm with can_modify_vma > mseal: Replace can_modify_mm_madv with a vma variant > mm: Remove can_modify_mm() > > mm/internal.h | 30 ++++++++++++++++++++-------- > mm/madvise.c | 13 +++--------- > mm/mmap.c | 13 +----------- > mm/mprotect.c | 12 +++-------- > mm/mremap.c | 30 ++++------------------------ > mm/mseal.c | 55 ++++----------------------------------------------- > mm/vma.c | 23 ++++++++++----------- > 7 files changed, 49 insertions(+), 127 deletions(-) > > > base-commit: 98808d08fc0f78ee638e0c0a88020fbbaf581ec6 > -- > 2.46.0 > >