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 504E2C4345F for ; Wed, 17 Apr 2024 10:09:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C96B96B008A; Wed, 17 Apr 2024 06:09:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C47676B0092; Wed, 17 Apr 2024 06:09:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B105A6B0093; Wed, 17 Apr 2024 06:09:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 91DF06B008A for ; Wed, 17 Apr 2024 06:09:39 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 16EDC1C0603 for ; Wed, 17 Apr 2024 10:09:39 +0000 (UTC) X-FDA: 82018602078.07.AD0808A Received: from sonic305-1.consmr.mail.bf2.yahoo.com (sonic305-1.consmr.mail.bf2.yahoo.com [74.6.133.40]) by imf02.hostedemail.com (Postfix) with ESMTP id 5154980002 for ; Wed, 17 Apr 2024 10:09:37 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WBmqykXK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (imf02.hostedemail.com: domain of marx_bhargav@yahoo.com designates 74.6.133.40 as permitted sender) smtp.mailfrom=marx_bhargav@yahoo.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713348577; 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=3J96mQmyEUCssCpbGqrADKBzbER7+RK33238CYRP2q0=; b=J7iZwFOIkTxwo8w9Teuc8i5gt9xssk0NtToPBUGuA+9u+O9vPlk3SWpUU+XAinOahxiGvr cvLRKSegKdG70CE7GXLfPsEwVfUeJZlfUoSpOz1ntWPotK8DGRc4Hlf72gq6L3G+qnRbHr uqi6inYVo3TwOVzrBsR314VLfVYIk9o= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WBmqykXK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (imf02.hostedemail.com: domain of marx_bhargav@yahoo.com designates 74.6.133.40 as permitted sender) smtp.mailfrom=marx_bhargav@yahoo.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713348577; a=rsa-sha256; cv=none; b=AgYRdBhZTfS64I5maBj7RsvZWItg12jgckd3I4anfrFHSlzybDG9NzGNHwWvhKwccBPYYO vg1v9gpzBZu68ylYZJg5H1am30p/hkNej5FaFPWfAhd/78XhBMjAfc+jQddPniOmBLlyf9 mMvmMGxioB/kJLOCYuhpxdo3FSUCuGM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1713348576; bh=3J96mQmyEUCssCpbGqrADKBzbER7+RK33238CYRP2q0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=WBmqykXK0pvLqMyX2yfBYVjfCsPfLJ2oZrLBtr78akIJBVUhZWFHROIzd3jhYtpI0nXyYiMcHpm8huYaOx5gDvgSoRy3dBwL3jn2yYoIHa+7dVudYI1joX1kvJnr8QoQC0NyUUo8aJD9Ns+ZL3+QYY/gV9IrgBXYt1DES4UIKcPFD7oogPk79vlLwIqfwvVqQZwMnsOwimFlBGhMYFhy9NumxT0yXnUDQM6lXqxGz9iLcXjk8HsK0IgfY0o9AiEDOWlIxLzmXSMw3w7yo1y4KJUqwm4cEu04VfVUOtS3ql7ZczhouvQA/FAKN5NeUnckq3J7DDrnA8B2D40gUvjuHA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1713348576; bh=bPHiqD78qciakUP/JyLY5bCA3T2p8yZ6yrrLx+ebOEo=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=VMj+aopvQtOrgRQwm0Hpm2JsddoasYqhfqZLCGO/fnUXod00TjQ5eAjaZ3KeqMME/5U4dU4ilU2asZcu53f01I1/IUQ2DfOzsZdTjjBxbilTPGp1shYrIGDgTosPtCrJvo5rL+X/uFxuqcnMelzaPN0L1Lc0ndUS0Ym/SoxIncsBCygpNupz49UbtUFox45Rw60aPG7n1ztmdDb2TANALUBCVur3WyReACyWPlxSikXNDT+vxng/wDFJuRfe72hr+OopEIDwOHLtsPH/WCJjbEhhLGwezFgy39zyWLnR19NtZzv771vmqLvSWBeWGFtXG7y3efVQaH4hM7k3Lucd4Q== X-YMail-OSG: yAQ3cmcVM1mleUdksINSuXBS3cCP8w07U7wiC.GSZqr1v7SV9tZljCGLzpQx6_1 hCmubpMCHC1xLcqTRYDtB2FLtKTTbtQ5dKJkApDzn3tPZ_xJRYAEY_jmAIMZFxlaNzdIuh8VJlfQ rISV2Ux6SPyLooXDSTfQT67S_ybxPbsFMleUU8im.qFPhBgm2vumKdvvrPN9k6vqwfJIEfwxU8y4 p.NobJNwXFUBQxSa.6Tvw59yTX8CB.99XtSs_eg4fFVofG1YGs618m0qFU_P76XfEEFl6BNEnj9w gE.17ewLdCxCz0aDA98TigOg2_MZ9YoE1BpUwrNTZJcJ1bZC5m49M95xy2ThvY8c2fEw8_b0wj8a eXwdl1VbVYYyOkkk19SWC9wuFUVD72taDzF3Q9f8Yujb7z_YBa2dCpcGxcHSK60RZa8nIQgEEqcM b3BwWt7ugLlPfjfIKM3fW.JrlrBAbRLDTE7uEr7zM70cpN4KPv3Eg4aaiORIxO7qmS8umfy63rY8 tg6rIWWbWl5.2AHWHgBomEFlM2clssLfP5HhJFL7n_zEQrsIp9aMrbSbE8WGrxP6jT.IwaH907uQ ltkT6W_4189tI1Wmi..V.Mbuss1Gc2SvuinaI1ycl34DqHXN45kt2Ve4ownwa4UjlvYRBw7O5laQ fpTGkoWD4oMTqXLHBw0UlwqQdpfIsifLQdKULhQHPObID_d.RPANy6KjtsPIhaH0S2dSflp1z61q 20FtWjz3UjH_P1WesxirwbJjHuPZNqe5Q8iL3J4NX1vz9XOz58KutyPTJHSATy5BkfRNpukEzWp4 EK2dPuzxUpHee3QOKquebsNA0X.wvfoe0mYwuO1UoXKNlA260fuoW91K1ZtLlallY72GgCm7PWSG ONcq.NDV.v3KDrpm9KVeaOetaE_B0dY.pEcVyVYRTy0bNRAhKPYdrxdZa0pdwPpcAnUrAxdvVAkA IkehZcqxhwqcDGTKXo1mWONy18fyIF7P80jwcFRWkC7aPoDHXjrXVxyxnv.05F5QjP107asJZmFq PVr83OwDdD8yDQ.Za_YHTZS_w3N4BdG1Hg45zfWVEYCiU3jM1esdISOfVRsduliDELAvFxYFLG.. PjlN2u.mOxAqs7TjEITOMJxQHLO5Lgfac_0UpuOgspabmmPCpznLW4eYO5yadqe8Au9Oehw9qXVE abYvF_iQJWoQbeHQhU5lnXYa8R4aVp3ftgEjBG8d27nCAcsnsFd7299_JguH5daYDT_n.KJ6wn6f MBX3KT3cOuBpA6rJREURZOdslo5w3T.TBoC.IQJ8YbLe.c0cYDueAvpio0OZ2wMCXpNXXCYRSfkI IjQna35L6sFh9Gxzvzd5iL4bbBovs6KPuVbMtGkalOub9u.HazZSwElj.CRqDpbDYtuNZMuPJTck viwIltk_znlM8TkJHOxsBHZZU7Md62eomMlQJr5Dqo.PJXWdHEP8Yo8bdlYPsah0g4ubIXwh2giw W_6v6cVszVt1NIuQFjUa4Z5yVXBEMw2v1dRr0Xo7tcO_4ROwCuzGXN_zInIS1tBwHfT36KjZS8Iw o.faSnblTV1hFoNe4vuCGu6yntXhV4s7sVPGL.xUN.61i3OdnTLEMNA_3HWjQ_h_jr3OTGBXOUs. 5FnCt._5AMsy6dKX1k_978hmg8gzweCqSM8U6np3v.qwCQvHHEbkbevKkbvNfpEJTBXZ9XUqcSO5 PJFqPZBL6ztFLAZrcPCrraRh1GYMx7mmhapKxwYfAID3a184npvvkE9o0orSrR6xeJt.PwrDltXx aaEgyGszvknz.2a30hoia3sekeNEGeJtrTHSpMtSSwsO8zRyN6NIVOSBgVuRajcDe4aIt.WcdIGs p_s_G7dxgGQ7HnvXnCsfl4keBN7ZynLbyTBFjvOg1lJFZYMWO4XGrAdbrWvBH2qXAQbnRdkKtue_ oTxZ866NU0X5hKXJBb5oyNOROOwMU17nJi5X3v3gR5x8OsjamqcBt3onMjjisIJ7znJm64o6wtz_ Sw8KEjN4C5i5ijn.NsMSp5dxv3jOm2oZbihWdH05e2ZT1sw5E.RGnLjGv_oaZRKBf8WHfKKXG6TO jgL5tgm8ZMIGMPcpzMTcpQMBuGu1RR31_RUEPCDhdvmAJjNp28xFfMFqunxup5O9KNM5gLJC82Rk qD1SIqCEWgoXUHn16lE2eTPxixXos.HK8CtVHVTKq881YEJ0PB_JSG0CUo3CpqZoQJQViIVmGJWF dO8kxNbrvFjvnQ.XlsVf5JrXCkFucF3MvXEYcyvnunjKIJ88j_C5HZQ7OziKB.adCsVg- X-Sonic-MF: X-Sonic-ID: efd07b4d-c530-4567-8b39-6737beda064d Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Apr 2024 10:09:36 +0000 Date: Wed, 17 Apr 2024 10:09:35 +0000 (UTC) From: sunil bhargo To: "linux-mm@kvack.org" , David Hildenbrand Cc: "mounesh.b@gmail.com" Message-ID: <1998899028.91244.1713348575745@mail.yahoo.com> In-Reply-To: References: <245378552.87900.1713345083646.ref@mail.yahoo.com> <245378552.87900.1713345083646@mail.yahoo.com> Subject: Re: Request for clarification regarding huge pages and remapping of virtual to physical address MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_91243_1073555471.1713348575744" X-Mailer: WebService/1.1.22256 YMailNorrin X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 5154980002 X-Stat-Signature: jztq5yu6r4b9a35pop7aioarp9bz8fth X-HE-Tag: 1713348577-180838 X-HE-Meta: U2FsdGVkX1+cR+1K3SJxRIZMQbP18sP+T7afWx90EwPJ12wIXSvFt68cvyHgHt417fftcr58dwZgXmBLvWo9CCD3em7Od2juROD6galOdlfjvem+/pAyrkUb3EHRVEIg8SItslnXU6P3fIs2XCNYwNLJVYUET2n7mnEL/vfdi+vPydHzW2CCioEmiAhWE9nqqp4LRVYrdH3VLSZWWjG9wCWrPTwX+aey54Rt608y2aanSxeUweJASNntfdy2GW6kaByz2DAwFkBUcMKKT6yaIhjwQTokknQKefP/C/CyVXd0xbzh3MAVMsg9hOloF0fkgWS1J1qjwZU2d7/PcnwIfmc/GfWkQFhsSjMfO85gEPzdSOExfouHjU07tLb2d52DlzH6mTUOp7K4ZG9TlgY2VRC8v70dYhDN2XD7RQh9QNoqzeHo1bKhwuIFjK8G+5JQbSCUnIMBv70pJJgj/FfYPbUJh+UhPsa7VRNMwXc4Is2h8yEFHNFOTJkZsuyQuTVvmmLRl1ZDzNuHQg3mkAQDLKvyX3oLFWLJzy+6GHdYt8ChDwwUis5pd5Zz0MigCXQi0ym0WYZLtpncBZePVhW34hJvEA5moAYehK7HN/uY15ZUD4d+5qC2Y1EWlEt9/OHTn0mebVkwhZu3cLLFbbnDuS0mbI0WC4ozhSj6xtn+JPf9ZWPcV13L1AYceC35XmG9JdrniLBvbVgC7v+WUs1xnik6v+xQNmYkGr6uIWlQRCY61T5W2MeH4zRgXnpRTbicu3BYCLp6gQaASFB11SGwZRPKUaDDEelcqPF2xPeIck68184KPn2CZNGs9EhV54gUg/64imS22vFoQhYgLsULODiG2yHtxM4IhSSgOzu7MmPRAkK7niYkIUCr4y28ShUiLEpra4tg5/cTCTzpoE1zaFIuXzdvMFFSAkqLlJOiRhNnh9tkZl6SrnW9ilqDJGt7RLJ5jvkneyNwJpuB72P TEZsYdIX 5pST72oRVykp/lSznQBghjYf+Z2pIpS2LS/NJ9kCU2rs4h1/xWi6Wh8lX3T0vDJGUPIpzXoTUURU4zZQzedwYCj1qQd6OF1HYqfZffzUlsEXtSdCU6/UT4+cMbhy+7YYjwkxhuOr9SJ7RkxWifAQ7YOvtyy+SnpaqIklO8hU/yywiuKHm52JaXbem8+uR8r5DYDZ+uhgmvE+Lgt02iIPFZdjVti/qm7iVzRnMoM3SIhkB3b7u7SjpIqTww62ljyLa54cGZqNQ3ZI3Ht4/F4cRlreFwqrCv7VkHE5Hfi5xDpndd/71Qhiv9b2O3nS56bRSK2PeqVJPhtBRjAH8ew6unGkGX2WcweoTAzuJG9u/emtPtTkX71fN6ZrD9U/+VLJlTQXIiz4XnyevcrpQg+Qsc76zTOPMzkPKxZFSYOpSZZpUPRA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.005755, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: ------=_Part_91243_1073555471.1713348575744 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David,Thanks for your response. So if i get it right then reserving the me= mory at boot time with/without the huge page, the page migration can happen= ?=20 Thanks,Sunil Bhargo On Wednesday, April 17, 2024 at 02:47:30 PM GMT+5:30, David Hildenbrand= wrote: =20 =20 On 17.04.24 11:11, sunil bhargo wrote: > Hi, >=20 > We have an application which relies on virtual address to physical=20 > address mapping to remain static. The buffer is allocated using=20 > malloc.=C2=A0It is in user space and we were using the mlock thinking tha= t as=20 > it would prevent the swapping the va->pa address mapping would be=20 > static. But it seems to be a faulty assumption. >=20 > If the memory is allocated from huge pages=C2=A0by reserving space upfron= t at=20 > the kernel boot up and then mmap=E2=80=99ing using MAP_HUGETLB,=C2=A0is i= t assured=20 > that=C2=A0virtual address to physical mapping won=E2=80=99t be remapped a= nd will be=20 > static ? Unless you have a kernel that has page migration disabled, no. You could use secretmem (which is currently not migratabale/swappable/=20 ...), but that has very limited capabilities. A "hack" would be to register that (ordinary) memory using iouring as a=20 fixed buffer. That way, it will be longterm pinned and can neither get=20 migrated nor swapped out. --=20 Cheers, David / dhildenb =20 ------=_Part_91243_1073555471.1713348575744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,
Thanks for your response. So if i get it right then = reserving the memory at boot time with/without the huge page, the page migr= ation can happen ?

Thanks,
Sunil Bhargo

=20
=20
On Wednesday, April 17, 2024 at 02:47:30 PM GMT+5:3= 0, David Hildenbrand <david@redhat.com> wrote:


=20 =20
On 17.04.24 11:11, sunil bhargo wrote= :

> Hi,=
>
> We have an application whic= h relies on virtual address to physical
> address map= ping to remain static. The buffer is allocated using
>= ; malloc. It is in user space and we were using the mlock thinking tha= t as
> it would prevent the swapping the va->pa ad= dress mapping would be
> static. But it seems to be a= faulty assumption.
>
> If the m= emory is allocated from huge pages by reserving space upfront at
> the kernel boot up and then mmap=E2=80=99ing using MAP_H= UGETLB, is it assured
> that virtual addres= s to physical mapping won=E2=80=99t be remapped and will be
> static ?


Unless you hav= e a kernel that has page migration disabled, no.

You could use secretmem (which is currently not migratabale/swap= pable/
...), but that has very limited capabilities.

A "hack" would be to register that (ordin= ary) memory using iouring as a
fixed buffer. That way, i= t will be longterm pinned and can neither get
migrated n= or swapped out.

--
= Cheers,

David / dhildenb


------=_Part_91243_1073555471.1713348575744--