Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Tiberiu Georgescu <tiberiu.georgescu@nutanix.com>
To:     Peter Xu <peterx@redhat.com>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        Jonathan Corbet <corbet@lwn.net>,
        "david@redhat.com" <david@redhat.com>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Ivan Teterevkov <ivan.teterevkov@nutanix.com>,
        Florian Schmidt <flosch@nutanix.com>,
        "Carl Waldspurger [C]" <carl.waldspurger@nutanix.com>,
        Jonathan Davies <jond@nutanix.com>
Subject: Re: [PATCH v2 1/1] Documentation: update pagemap with shmem
 exceptions
Thread-Topic: [PATCH v2 1/1] Documentation: update pagemap with shmem
 exceptions
Thread-Index: AQHXrj+D4T8obcdGHUe6vvWc8xL+VautSQuAgADmeYCAAGf/AIAAEdEA
Date:   Tue, 21 Sep 2021 16:08:29 +0000
Message-ID: <C983908F-7AF4-410B-90FF-DB4B9A06E917@nutanix.com>
References: <20210920164931.175411-1-tiberiu.georgescu@nutanix.com>
 <20210920164931.175411-2-tiberiu.georgescu@nutanix.com>
 <YUjb91tWhd/YAgQW@t490s> <F6A49621-C7A4-4643-95C2-F47B02F132D2@nutanix.com>
 <YUn0ikP4Gip3Yc6L@t490s>
In-Reply-To: <YUn0ikP4Gip3Yc6L@t490s>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EKhDkBOWm2ArfZuHLtGxNEpk8h8QCf1AjSI5y56CYynf7rSW2xlxWtyF8Tkb?=
 =?us-ascii?Q?Y1lAxq95FrOoLBUCkB2GtuMl9VNAUdAekr+7dRRWlMKoDJk9TECbw5LRdt4s?=
 =?us-ascii?Q?O6uWIFccUCtTNswIUDBRCT73F6xFWeVBUfaNsYNfjhai0Lm2lvI647M/pjgR?=
 =?us-ascii?Q?Zhsz6lFzBUYMPp3hYLOB2L/wMy6iTGiIkzSxX/hyF9obRpwNYMeNRHFyVoHw?=
 =?us-ascii?Q?gU7RP10uEayIOua0B95VXsRa/KUAGblBE+1RGq179BNvsHGT4dWBvDaALXCN?=
 =?us-ascii?Q?ayK1Ay4OpKVyaGCyLleImsEAqPe95H4QkPebOC7C8EuoiAgKETdiuGAQJknP?=
 =?us-ascii?Q?xewRhV0M5pVwp61hiMKkU6Mmn3deHuNic1YF9VsS/e6bdxw/+DcuzcMVm5Au?=
 =?us-ascii?Q?m9BV/4fZ76LDlnLF3ilEFalqW0uh9QL1Yo1reN6miestks/T4K4xWWEGnayz?=
 =?us-ascii?Q?PE/QyweuiOBDyVb8jBMEGCJXcq45dlPgrPVcb/6sLnEE4sNLqN+Qg/Dca/L8?=
 =?us-ascii?Q?fXbRTr/KEc8g86qf/1zz1/X7ft86bdBb56sZ6OX5hbDukcppwUVUmED7Wg48?=
 =?us-ascii?Q?oUZq4SNXvyd8PnLCKiFvDOmpU3V/TPmOzvZUSE+6tbryx3GuX9pFZsg/ALBB?=
 =?us-ascii?Q?VQ3+PCp4RR7ltCtoonhUUSkWSHn5AOMdwqjdezHctIRNIwkj2WkIHKVBMUZK?=
 =?us-ascii?Q?6+2R7adPVWnHjznxIs0Xb/b0n9UDRMl/HPoz8YMNLoTHOL+smh8Uc2IvODAr?=
 =?us-ascii?Q?MgjU6tTnWdKcj6OWHZ070c5VSzALyOdjkZMFdNAwZQLvHtH4jwAlyGDlwfgn?=
 =?us-ascii?Q?l6VeBMZ8HyIa6tPFGG8sXm2pFdTBSRgOU6oWEgjDBq9MUDl8yz9qgPWVmYsQ?=
 =?us-ascii?Q?EqbnksEjyvpLk4uLUinbjL+ZR5mz+d3xewax0L0X3zv/miBvRtxIZTvaKdZR?=
 =?us-ascii?Q?MWtBEX5/Pl09k42jQXLmB9noEJ/BkYnJypOkEF7TieA93QskuN+YZaG55plE?=
 =?us-ascii?Q?OzriQi93XvUJUptvgvzm2Pr41qTJM1k7pELHZk5IoG5iG1U8HKpCUwFNLeEQ?=
 =?us-ascii?Q?7h2nUCYr8kC24AnxoiKBgSJGkdFsbOCL4f0JRxYTCKslRXs3SY6Tkxyg+GTc?=
 =?us-ascii?Q?lLutxO05CQK65zO6ZNVe6tOEw2hqPtbtCvVfgqaJ5S2Sqfke1QVH0FGpd3PN?=
 =?us-ascii?Q?Tza/YyTQ5/eKb/RqtJ1g70dE2UfM9GM1rqlyErbps4LX354EgFYTHqrG9/Vr?=
 =?us-ascii?Q?Fd7jOSI7QfdLpgAUEa8p9lheBJYHHKTwxtJFJ/p4OIdJwTZXz5lzTmWgv/jL?=
 =?us-ascii?Q?YZJZwMHVOm9o+uYU1OiczWAk?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3C3F40A8DD3AD84FA1709450D1D8DE81@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nutanix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB5578.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ba72d92b-ae2e-4aaf-6b07-08d97d1a0d7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2021 16:08:29.7979
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bb047546-786f-4de1-bd75-24e5b6f79043
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6jD5s2pcZmNfv17zNTc5Y4fRBp6Gy2E0fy+mYvaRJi01nM5M8PvppQE8jus6N3QNPm6POluMICgFwKz6yeCPvp+F1i38dhBIAHKSd+AE1Sk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6906
X-Proofpoint-GUID: GZNnUS6pg0WgUCsIoTwpM_ODm2rHguHP
X-Proofpoint-ORIG-GUID: GZNnUS6pg0WgUCsIoTwpM_ODm2rHguHP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475
 definitions=2021-09-21_04,2021-09-20_01,2020-04-07_01
X-Proofpoint-Spam-Reason: safe
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On 21 Sep 2021, at 16:04, Peter Xu <peterx@redhat.com> wrote:
>=20
> Hi, Tiberiu,
>=20
> On Tue, Sep 21, 2021 at 08:52:32AM +0000, Tiberiu Georgescu wrote:
>> I tested it some more, and it still looks like the mincore() syscall con=
siders pages
>> in the swap cache as "in memory". This is how I tested:
>>=20
>> 1. Create a cgroup with 1M limit_in_bytes, and allow swapping
>> 2. mmap 1024 pages (both shared and private present the same behaviour)
>> 3. write to all pages in order
>> 4. compare mincore output with pagemap output
>>=20
>> This is an example of a usual mincore output in this scenario, shortened=
 for
>> coherency (4x8 instead of 16x64):
>> 00000000
>> 00000000
>> 00001110   <- this bugs me
>> 01111111
>>=20
>> The last 7 bits are definitely marking pages present in memory, but ther=
e are
>> some other bits set a little earlier. When comparing this output with th=
e pagemap,
>> indeed, there are 7 consecutive pages present, and the rest of them are
>> swapped, including those 3 which are marked as present by mincore.
>> At this point, I can only assume the bits in between are on the swap cac=
he.
>>=20
>> If you have another explanation, please share it with me. In the meanwhi=
le,
>> I will rework the doc patch, and see if there is any other way to differ=
entiate
>> clearly between the three types of pages. If not, I guess we'll stick to
>> mincore() and a best-effort 5th step.
>=20
> IIUC it could be because of that the pages are still in swap cache, so
> mincore() will return 1 for them too.

That is my assumption as well.
>=20
> What swap device are you using?  I'm wildly guessing you're not using fro=
ntswap
> like zram.  If that's the case, would you try zram?  That should flush th=
e page
> synchronously iiuc, then all the "suspecious 1s" will go away above.

Correct, I was not using frontswap.
>=20
> To do that, you may need to firstly turn off your current swap:
>=20
>        # swapoff -a
>=20
> Then to configure zram you need:
>=20
>        # modprobe zram
>        # echo 4G > /sys/block/zram0/disksize
>        # mkswap --label zram0 /dev/zram0
>        # swapon --priority 100 /dev/zram0
>=20
> Quotting from here:
>=20
>        https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__wiki.archli=
nux.org_title_Improving-5Fperformance-23zram-5For-5Fzswap&d=3DDwIBaQ&c=3Ds8=
83GpUCOChKOHiocYtGcg&r=3DrRM5dtWOv0DNo5dDxZ2U16jl4WAw6ql5szOKa9cu_RA&m=3DXW=
zLVqSSl8CSEcw2x6sUmspJhiUJei2gq6GTiaky8hk&s=3Dk3BDgO9LN63Nn3vxorlc41MlUYzOU=
N0efajz4lol-k8&e=3D=20
>=20
> Then you can try run the same test program again.

Thanks, it worked!

Hmmm, so if we put emphasis on the accuracy of swap info, or accuracy in
general, we need to use frontswap. Otherwise, mincore() could suffer from
race conditions, and mark pages in the swap cache as being present.

Do you reckon this info (frontswap for mincore) should be present in
the pagemap docs? I wouldn't want to bloat the section either.

Kind regards,
Tibi