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 X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FORGED_HOTMAIL_RCVD2,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, PDS_BAD_THREAD_QP_64,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C17CC433DB for ; Fri, 22 Jan 2021 18:42:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 717A323ABA for ; Fri, 22 Jan 2021 18:42:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 717A323ABA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=hotmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B628A6B0005; Fri, 22 Jan 2021 13:42:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B13366B0007; Fri, 22 Jan 2021 13:42:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A01BD6B0008; Fri, 22 Jan 2021 13:42:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0094.hostedemail.com [216.40.44.94]) by kanga.kvack.org (Postfix) with ESMTP id 8C8C46B0005 for ; Fri, 22 Jan 2021 13:42:22 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 51E238249980 for ; Fri, 22 Jan 2021 18:42:22 +0000 (UTC) X-FDA: 77734281324.02.bite11_45069312756e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 30B2310097A3A for ; Fri, 22 Jan 2021 18:42:22 +0000 (UTC) X-HE-Tag: bite11_45069312756e X-Filterd-Recvd-Size: 12144 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010018.outbound.protection.outlook.com [40.92.10.18]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Fri, 22 Jan 2021 18:42:21 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nNu++Gqk+/Wd5Bq26+BJHznJTSJ66O21kErpZOPH4tqqkzhOc25X9aBjxA0WkW5FX9yvL+rnRoyG+CBwQ0VsXs99EBZ+H1noQ3lPwEEYSPMXgPPLOxyRhDa5MZLyj5M4SPbwG4pH/N/JxlKfIo46pv1H0mTjBUDg9UZ7OtjFX3Y5gew4C2cfFT0XH0nGMWUT6Kw0kScmWqJEbCZkQkKq9HI70m9oWWmf2sF3GZkiNJuzuCHjC5XPvQSClfn8+45nTYSzywSlsZQPXvfQ9g9VRXR1+LS9gE8XpWpzMC6iCo8vj34oj2VIK6HAq7M8xPkZxSNC/3+pDvZiBUm1mg+/GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p1lmmHmvp6p91p8ZCwDLZtessbHdxM32ZpKotZHBm/0=; b=WK8q+ZtqkHlpduTB4VN6bat+Lui/SJqzMC7AnrGtOGKTgczHvPgGe5MVqWBL45tpm1UEOGLksPzE+dq7t39rshFEYiYRrblAtV7kGmL6H8abRoAtx/eduEpVDMUU5wOTOZvo4iY18qKyLb8ek4EyiIH3Ra88i8d9ZA+gPZflODZqTSle6yMSHdWv2e7AMv1lbBwMhRHds0YT/B6XCS/iD9JvGIHhmGJGHo1mk3pC7eB29g2tZdrOqXQc6IKmzdVua8XQwMR18ZiW9B86xElZcExm/TBbZrlM5IfPNX93oeIgo4/ff+0BwSLyC+9AVcv+iJOpHG7vcEjKzudgb384vA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p1lmmHmvp6p91p8ZCwDLZtessbHdxM32ZpKotZHBm/0=; b=F0bbHbr6vYrKE23Tm7iPh/GKzbw7wMDLdMnjBB7bvGDjQ3TXzZLsivkR0Wd3Gc3kZxY39fCUIgMo2KCbgv0AyB+vJtHo2p8vTVXbQaXIVqvBb1hLbBeN8kx1s3FubUHif2CfXksnLuAeQNbl4LpZv4l3HN8mXnKWcYoPEPLvbZdcsTHOnAMTFz/611w1t0G0NmEqhm6bC32i7hiHOWCjOZJufw4EUhQ3Nt22j421ME1L08AUURnD7ljP5bg57wEpOgTSlseJGy8GULaiS14Sx5LFfLhJR96wbr9WNJZ+RjtYsU92wkU52KnuoR0fGibctEAIZ4eswRmP3IyJlPNbpg== Received: from BN8NAM04FT061.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7e85::51) by BN8NAM04HT249.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7e85::368) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12; Fri, 22 Jan 2021 18:42:19 +0000 Received: from BYAPR12MB3365.namprd12.prod.outlook.com (2a01:111:e400:7e85::48) by BN8NAM04FT061.mail.protection.outlook.com (2a01:111:e400:7e85::234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Fri, 22 Jan 2021 18:42:19 +0000 Received: from BYAPR12MB3365.namprd12.prod.outlook.com ([fe80::9589:c058:85a2:6d5c]) by BYAPR12MB3365.namprd12.prod.outlook.com ([fe80::9589:c058:85a2:6d5c%7]) with mapi id 15.20.3784.013; Fri, 22 Jan 2021 18:42:18 +0000 From: shu wang To: Mike Kravetz CC: Linux Memory Management List Subject: RE: [Bug 211287] New: Softdirty bit does not work with hugetlb Thread-Topic: [Bug 211287] New: Softdirty bit does not work with hugetlb Thread-Index: AQHW8Fm3NIyUHa3YH0Gonp3Nwjgz6qoz+Kkb Date: Fri, 22 Jan 2021 18:42:18 +0000 Message-ID: References: <999775bf-4204-2bec-7c3d-72d81b4fce30@oracle.com> In-Reply-To: <999775bf-4204-2bec-7c3d-72d81b4fce30@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:105531B319EA89C8D7956C30932661A7173FAF866ADC22E7B3FDDE24FBA6B1B5;UpperCasedChecksum:6DF4D305C02195CE6E2F8B1FFF2054AA75C2460D7C8B17C0D2EDAAD5137FC58A;SizeAsReceived:6919;Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [EBOG3KwqSSNwt0L2NxvMyGKo2KTNc+hSEDWMVr4/QWg=] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 07bba356-62d6-4e90-df2d-08d8bf057254 x-ms-traffictypediagnostic: BN8NAM04HT249: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xt+/eUN2En1gqgEZ3jPKKjTc3v+MdFxUOBFg1d1xtlySbJQbqlkDbYRM5LdApR9TmkLRK9pwozP2C8r0HByW9LVKl6I6rJgQoa5laQhtoekqY7HkoiORcm+aBUb3F9OU8inzGGKFAbJEd09sqpirmsXPuwmSJ4RkHLjbmHqISHcfW3c8vxq4SC0A6HRDrhYeFSscGm0eQl0plXMckjhlkMCEyJFohPGUWPwMkN56hGaEulG85qsgvDK8B44UhI+YWR2NTm0IMOs7jCeSIwWMX5UlpKeiR+V1DA0f7ogRhRmS2Smii/Ee93jTei2ryxN2NN+TTlP59a/QueD60rd6T+UBfgc4kzE23BCWVxWNaDWYYwxEPPeQ0qezIFzVK17P0hTTiQ9prFINXXeoyHHeokW2r+4Szyje++iIXaTZDZpFRjhalO3wsdb4m+HX1VaW x-ms-exchange-antispam-messagedata: /EWgQXYECBU9Oh+CgE/k8N4mku6T5yMeu56D8ZUZWa64PT7nTT0tOaNtL3KBo7NuaNhQkJZFojOdkkuaoJlJ1h5EVsbQ0tlvz1uer9kSltfysd+kDY1JGeGCKM5MWJktYOJB5RTjEcvzdNiJy4ebIw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR12MB336517610C8BEABEFBF95EA9F1A09BYAPR12MB3365namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: BN8NAM04FT061.eop-NAM04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 07bba356-62d6-4e90-df2d-08d8bf057254 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2021 18:42:18.6182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM04HT249 X-Bogosity: Ham, tests=bogofilter, spamicity=0.037881, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --_000_BYAPR12MB336517610C8BEABEFBF95EA9F1A09BYAPR12MB3365namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Our use case is: We maps both PMEM and hugetlb DRAM to process=1B$B!G=1B(Bs address space to= provide large amount of memory to the application. Periodically, we clear = the soft dirty bit by writing =1B$B!F=1B(B4=1B$B!G=1B(B to the clear_refs. = Then, we check the page=1B$B!G=1B(Bs soft dirty bit from pagemap and use th= is information to track write activity to memory. We migrate the data betwe= en DRAM and PMEM based the write activity for better performance. Sent from Mail for Window= s 10 From: Mike Kravetz Sent: 2021=1B$BG/=1B(B1=1B$B7n=1B(B21=1B$BF|=1B(B 16:58 To: malate_wangshu@hotmail.com Cc: Linux Memory Management List Subject: [Bug 211287] New: Softdirty bit does not work with hugetlb >> Start Bug Report << Bug ID: 211287 https://bugzilla.kernel.org/show_bug.cgi?id=3D211287 Summary: Softdirty bit does not work with hugetlb When a memory region is mapped with huge pages, the softdirty bit is set on= ly right after the huge pages is mapped. After the memory mapping, if the softdirty bit is cleared and the memory is written again, the softdirty bit= is not set when reading from the process's pagemap. >> End Bug Report << I am not surprised with this reported bug. The page fault code diverges pretty quickly for hugetlb pages. I have not looked closely at the details of soft dirty, and do not immediately see where in the fault path for norma= l pages it gets reset. But, I only took a quick glance. I can work on adding support for hugetlb. Can you provide some details about your use case? -- Mike Kravetz --_000_BYAPR12MB336517610C8BEABEFBF95EA9F1A09BYAPR12MB3365namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Our use case is:

We maps both PMEM and hugetlb D= RAM to process=1B$B!G=1B(Bs address space to provide large amount of memory= to the application. Periodically, we clear the soft dirty bit by writing = =1B$B!F=1B(B4=1B$B!G=1B(B to the clear_refs. Then, we check the page=1B$B!G= =1B(Bs soft dirty bit from pagemap and use this information to track write activi= ty to memory. We migrate the data between DRAM and PMEM based the write act= ivity for better performance.

 

Sent from Mail for Windows 10

 

From: Mike Kr= avetz
Sent: 2021=1B$BG/=1B(B1=1B$B7n=1B= (B21=1B$BF|=1B(B 16:58
To: malate_wangshu@hot= mail.com
Cc: Linux Memory Management Li= st
Subject: [Bug 211287] New: Softdirty bit does not work with hugetlb<= /span>

 

>> Start Bug Report <&= lt;
Bug ID: 211287
https://bu= gzilla.kernel.org/show_bug.cgi?id=3D211287
Summary: Softdirty bit does not work with hugetlb

When a memory region is mapped with huge pages, the softdirty bit is set on= ly
right after the huge pages is mapped. After the memory mapping, if the
softdirty bit is cleared and the memory is written again, the softdirty bit= is
not set when reading from the process's pagemap.
>> End Bug Report <<

I am not surprised with this reported bug.  The page fault code diverg= es
pretty quickly for hugetlb pages.  I have not looked closely at the de= tails
of soft dirty, and do not immediately see where in the fault path for norma= l
pages it gets reset.  But, I only took a quick glance.

I can work on adding support for hugetlb.

Can you provide some details about your use case?
--
Mike Kravetz

 

--_000_BYAPR12MB336517610C8BEABEFBF95EA9F1A09BYAPR12MB3365namp_--