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 53FD2D7832E for ; Mon, 2 Dec 2024 14:54:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A554E6B007B; Mon, 2 Dec 2024 09:54:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A03976B0083; Mon, 2 Dec 2024 09:54:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A4756B0085; Mon, 2 Dec 2024 09:54:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6AB226B007B for ; Mon, 2 Dec 2024 09:54:21 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 03D8D81CCC for ; Mon, 2 Dec 2024 14:54:20 +0000 (UTC) X-FDA: 82850314302.23.80C6F14 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf18.hostedemail.com (Postfix) with ESMTP id A038A1C000F for ; Mon, 2 Dec 2024 14:54:13 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gHNeXD3l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of 9erthalion6@gmail.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=9erthalion6@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733151247; a=rsa-sha256; cv=none; b=g4a4ebdSWEUC1fI8bz/wcmJDxdNSQybErmepzMZZvrZvOi8LwxQyhaLzCPurUaBdqq3LL3 pjILLbbjBMcB99q2FH2Ni3BYI1W5KaialZZEgJCAKfUdSG6Nwe9zVDDazVKtNr8ICa12tH ZcZqWzu2LizAtEgFCj/HoK/DeO3sr3I= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gHNeXD3l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of 9erthalion6@gmail.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=9erthalion6@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733151247; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3c9/wlbD2ONkA4Thz9i6rgiowKTPTqY8SioQq3SwjsA=; b=mSHgLF9eh7SwpGZ5rCZwmUWFF8VBN3hqPgFIKuJA268mKAgeXv/EGCJIXzEUE+pTjLI8Kv UCV2RXBK+n6ny4RVJNHnKTFaa8dl9PYdNR14s9MeEUo/vIqKbu/Jyh7ZYP2MnR3dhOiBzg J2nHt10Vjdq3KhcygpwtlcaoSzub6JQ= Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-53de8ecafeeso4699946e87.1 for ; Mon, 02 Dec 2024 06:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733151257; x=1733756057; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3c9/wlbD2ONkA4Thz9i6rgiowKTPTqY8SioQq3SwjsA=; b=gHNeXD3lYFigaNETI5Z90XwsICdBD7drFaD18GV8FQl4+/HTFAcy5izJFNQ9Rj6bUE qzqHvMW9piR3HMfxURkBJWoF8QRbwjglxYWq7yFmKRzJoZ5y4o7Lod6N8TcMVQo49Fay C8OYdIhiCqWmMhEjuBsDS/d+/qJqqVl76QiLZIioK+HfXrBr0AVE0jmve9S8ia9bBJ3e K2PcNuzTnWoivSGoMud0HWnygKDcqqiX37fEXsZNYiM7MkMrmKKn7Q6EIVjDx1JdHq9F Z+YeGeojLixHxDSRgwS0CKeEFs1O8AKieywRepi1eFkBLXXii4rAn9r4LsOtz3E2EVqS TE4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733151257; x=1733756057; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3c9/wlbD2ONkA4Thz9i6rgiowKTPTqY8SioQq3SwjsA=; b=AmDEB3mPnn7Dvu3T+Aq9dFHGKh/zoh7Ps6A+itWyYwSOfRb8aryVphajj6bjpVch1V WaleC7rEm7FCBuT5zI5zK6t0z2v8VX8TaX940r3+OllmsA+hiPMiwsIH1gTG6pdzpq6g LODoRw6RMuEWh6EU1RFrED4TZazMNnWjzDXQmmx0YXQ5JAusEi1v/u2tZ/9ZlIrp3uCZ YjkcIVQFXiaBqzpZ/PXRq4ra3pyJZak+ai8GOao816UEuuLox0XDVQU51Rfxl/mtbXvd lqWni4RfFjmtzRBDATOIYZaPqlVz50Z05JkzG3Pb1EaeTh2SH2j0cNSAjXB4x3SnMrSB EkMQ== X-Gm-Message-State: AOJu0YzW13/fnvT+v5sYzZ8S94gLvsgTRRUpnaAYwTEAOtPVpKx4rL6e 9COYQZo5Ne0uHOnFXYpt3sMhQ81zGxkGMq7oUYDocWH4JJi8JNtB7+vtYlgw X-Gm-Gg: ASbGncs18xifN/o2caFnKbN5+bHeI5KWogq5mDX3FmkH/Xfbs9Jrp8sGKXU7vfBnysh pOBvog9R/vIGzu4kfX0Bph5cpM4ggraibsLkIbaQCj/aaChJK9it2tXXG147oGpW8CE4rK1ezxf nQTN/NwKNshFRSkuCX//d1g0Co0wBDC79+RgDx3w+lfAvO0JGeS0hZbUToGoevR3/H0QD50YlkF XQOITIOFa8/ltfqnlSKfdJeWF72qZ6uKZMrVKo8hfJTK+phB3gHgwibEqE/JSf9WMMXdimSDZt1 yYCYPTCkSv6d/dtxW8uEoqmu/TEOXAKk9oclrYlc5V2zVOO/siPWC5R+Wc0lBiQ= X-Google-Smtp-Source: AGHT+IGrZBbMurRyhbHR2hu5VTuWAdTaGzFV6nbRwCkxVePccso/ssjSARKCAuF/OtsQWB07lGBM8Q== X-Received: by 2002:a05:6512:2304:b0:53d:e76b:5e6e with SMTP id 2adb3069b0e04-53df00d9cf4mr12361698e87.31.1733151256702; Mon, 02 Dec 2024 06:54:16 -0800 (PST) Received: from ddolgov-thinkpadt14sgen1.rmtde.csb (dslb-178-005-232-220.178.005.pools.vodafone-ip.de. [178.5.232.220]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa599903e6esm516189866b.136.2024.12.02.06.54.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 06:54:16 -0800 (PST) Date: Mon, 2 Dec 2024 15:54:14 +0100 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Matthew Wilcox Cc: linux-mm@kvack.org Subject: Re: [QUESTION] Resizing shared mapping without clashing with others Message-ID: References: <3kpxpd3dbjgg6epasi2554c4qyils4t3cm2pjnyzer7gkyoaxl@khhdxjiggyhp> <20241201184410.gl2huwqkbdwm6jvj@erthalion.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A038A1C000F X-Stat-Signature: oqok9asfwa7b5x6jurejnoc4a7hpffc6 X-Rspam-User: X-HE-Tag: 1733151253-210487 X-HE-Meta: U2FsdGVkX18tRCFq2YFd4c0FkUI8m4VMuuXxMMfZ7ebphWI+Lvj6kqHeKUAyx6xTKW1fOGaxcAPT0/K3xjWyBr+IOmJnEg5NTTUnsJRinTArP5qqtjiS1V+LoCB2Q0fJJGbJZhyjaF1ltjU1jyxGhyWbRVj/VLODO9I/AQ9xriiFJ/+SFmCO0MLfoFtYSfPubt59YGqY4U881cDpKoyOH0sxS5NLg51ljer1UeS9ocG5uJps17LhnLm6H/u2a+iksQv9/CWskTey0XT6TGHuLkefHlfBwL+3Se2fbodHvnp+VbeIOH1LR6BezUStRuKu6X+Lvm2e/XGjqm/F2Fb0HxUBKf3ZBCu2YIT9MlNkFFDamUKC9e07h/0iniQ2AWAQZasD6TLLrzWQ0oAX/07mRnxzatQBuNUei2qblEuIE6qOjAqe0pcU+7ueT61TagK+TLau0kRtG7Otpce4zGu6xJIkVBN8+VJ5v5WARxvULk67aKIXH1DmtjK15IJQ8fyrs+BnKqwDV/rm2At/sx2Cpz/TKxEM8kluplXciHanFNCPHx0k62hKjzAnVS/UzWIbtI7sxNjThFmhi81IaU5ujUduUL1M0ooQiw/9mAWPBG9i73sGCj2J06JM875ZeDsCOsJ+D3K/6g+Y3A5M8MDDHBubQx60YNFhhhBp208htUtifnfXqRAi9sw1LACzdI/nUQSp8VZpQHdX8AQZjBQmsBBQVyvNDzOPC4t5QJQDD7EkQgiGQsxxhAYkgVrZjnehoGXf7Ht8lH402Jo2eHBMc9vZJ4SnExqPreayVjj4gi40kZpk42i/lNF0y8sxOiQ8yyWnmQWF/vVfvpICqVhbTYAu3mJAwWooNRAJASgaLE1BkONxe4rZrAcjvUykVpIfxEalUq17UvwKRay50YAiy6elAFS1o2Aq+h+rtzQEl+ruEwbKmYOlDIss+yRgbcP7t7LeZg0W+KGuZvNZE3D Ld9K/DSt Dwnu/JmvcR7RF2wabwxMX1ucTPNY5/Tc6ocujDc10OuuL1K0qUsC5uiYRTUicPdUQ/Lsh4NRXWc5snUwTaxmRyg/q1CLVmKiqNjAJ3mi/5NdQ9S5t7oZWAG8GBm9oY+xhFiAFwDJOHiwHESqG2MB1sw4vIwUZr3LxVWZn4RUfFWtcf+GPXmR/NBNbcmD9eI4luuPRxVmAgktZO+kcgQzjNeOsmRMD3Nt+o5y5Rr8BXl9kP+vdcssQOPFFQg3DKn5H1a+y2aEScCx2HimB/5cLEgwI/ADNLeZDhvW2povOCB25T0sHsq//x3GZ5avdtKgOcdr/AhPURFag3yEtiLsg2pkU5HDJGmwVBv+7GRznegqba4Y9CkcNKlLvFoIRjMYFplK4FpHbxywdCOg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000012, 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 Sun, Dec 01, 2024 at 08:57:07PM GMT, Matthew Wilcox wrote: > > Right, mapping with the larger size than needed is one option we're > > considering. But there are few arguments against that: > > > > * Folks are wary of unnecessary large shared mappings, since in the past > > there were issues with OOM killer making unfavorable to postgres > > decisions because of that. It might have changed over time, but to > > confirm that will require some investigation. > > > > * It can cause memory accounting problems. E.g. if we use hugetlb inside > > a cgroup with reservation limits set (something like > > hugetlb.2MB.rsvd.limit_in_bytes), then such mmap() will be counted > > against the limit, even though the memory wasn't allocated -- meaning > > that we claim some resource without using it. > > If it does turn out to be a problem, you can use a similar trick to how > ld.so maps binaries: > > mmap(NULL, 2055640, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f221a758000 > mmap(0x7f221a780000, 1462272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7f221a780000 > mmap(0x7f221a8e5000, 352256, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18d000) = 0x7f221a8e5000 > mmap(0x7f221a93b000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e2000) = 0x7f221a93b000 > mmap(0x7f221a941000, 52696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f221a941000 > > Although you wouldn't want to do consecutive mmaps, you'd want to use > mremap() with MREMAP_FIXED -- not to change new_address, but to expand > length over the initial reserving-space mapping. Hm, I don't follow how would that help? From what I understand the suggestion is to have an initial mapping to "reserve" the space, right? But this initial mapping would also be a subject of reservation limits, mentioned above. I was originally experimenting with that, "reserving" some mapping space with PROT_NONE, then slicing off chunks of it for real usage -- but in case of hugetlb and a cgroup it was accounting against the reservation limits for huge pages.