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 3BFBDC77B72 for ; Fri, 14 Apr 2023 22:02:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAC6C900003; Fri, 14 Apr 2023 18:02:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5CE5900002; Fri, 14 Apr 2023 18:02:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 924EE900003; Fri, 14 Apr 2023 18:02:32 -0400 (EDT) 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 85F33900002 for ; Fri, 14 Apr 2023 18:02:32 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 565441604A0 for ; Fri, 14 Apr 2023 22:02:32 +0000 (UTC) X-FDA: 80681371344.21.160AEDD Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf10.hostedemail.com (Postfix) with ESMTP id 7747CC0030 for ; Fri, 14 Apr 2023 22:02:30 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=uQpTlspP; spf=pass (imf10.hostedemail.com: domain of fvdl@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681509750; 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=MQuB9JCPITcGs+8HPntMmVSm61Ab+fnUpiW2TFHYHeE=; b=QoMwSy2L0xQR/7Z3n0iDnp0nmlSzSSycniTxu6f8TXYZ4AWiKm2gVlnDD1nVEvou6QUK8f sAXwWvqlWe/W5+texwcVdyNbCpMt56VMSseWlhVHz2bKscDUHT5KB3aG53XrxXlB6zjPJP kRB7J7j4dZIzrqVUV9q1H7Bi4ilwt68= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=uQpTlspP; spf=pass (imf10.hostedemail.com: domain of fvdl@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681509750; a=rsa-sha256; cv=none; b=1bsHkTyTWAPocGV0lQZJ2+6xw45otcfHgVadGe47ZKAr8RFFCRisw5ruAkw+/FCNJkf8CW 7aL9a5vjHEI47ZuFj5eAs1dO4vXgijTDLKbD0hAqrEUgZ2m/2HUMFQZ6TfHjOeaZdXkLN8 twKUYJzF8MBjiFp8i+OBtx7O0ge0eJ8= Received: by mail-ej1-f41.google.com with SMTP id jg21so48723292ejc.2 for ; Fri, 14 Apr 2023 15:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681509749; x=1684101749; 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=MQuB9JCPITcGs+8HPntMmVSm61Ab+fnUpiW2TFHYHeE=; b=uQpTlspPi0frg0JzINki3uCSt7EQ5x2lIGx/Jr1wFzNrfNsbCmIQRvQ1hrsoNNfS/v XrYRntGvOyQ0xNt9Np4/jI341PIvSXRPeG0vSEapvvFhriZgmhSwv88FI1+oembfKq1V 8qZMRetKAwhF+WHdW3t2T0O3P1dGMgypsnyxbx3nz3t8GnkY9Xt4AxTu3E1bYp8rwjZE HDnoXxe0Jl6cYzHLfNqBL7DxH1kGYLuoB5lfvGdYbj2Ea2gqsV7bGivkTM9nA5MmvR8U rV4iz/8fIzWcOJ1V5EkV/Phy+fwSK3o8vZ4Lb1yHWH1IUrHvpWHcHmNJ19h0jA7BokWT eCTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681509749; x=1684101749; 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=MQuB9JCPITcGs+8HPntMmVSm61Ab+fnUpiW2TFHYHeE=; b=WO8tOlvt70z1LIpILyFjejeBHX3f5V6UhltqhTvGzy4Qf7FY0DPkTV9PCjDanqiZRW kWtP9KtBB5yZ+/gyttnl2MWQA2MAhs3cNK8YPmMrU3kX0t3ws6mFaTrBjmWalX5YQH4j rZUjx5z+wudV18CtvAM0KtS2SAQZK4kXGA8BXQmFrTAXY6mW/t6D8d5ohuIgaNUlJwgT F6/vzpXXkBK9E11weq4RXSaPw9VCoWgtNNGobuWNqQKFzQxvjPko3Wuv9907bj5iuC79 Wxsyq5I3ylJajJCk/OhlwYrC2VSYyqLmQkb4D5ofyBeGyARi+Et2XNaHiTWNmt8mlous Wclg== X-Gm-Message-State: AAQBX9f/UXl9tiPX689CCgIu+oe/tGIa/tkqMKXIDx50YYjRcXpnOpAe rl51IWh2c+kwTpqlzfO9FfwDKTjsDCUCIEQhy3oMfA== X-Google-Smtp-Source: AKy350Z2qGZgN2hDoy1aETuvpCsfxE3LE+VGFXIFcMKe6mqaUWE+80tTq89vHOsbH/LgewxQIexF0XRH53ySfc/n9e8= X-Received: by 2002:a17:906:584e:b0:94e:e7cb:2cd5 with SMTP id h14-20020a170906584e00b0094ee7cb2cd5mr266468ejs.15.1681509748576; Fri, 14 Apr 2023 15:02:28 -0700 (PDT) MIME-Version: 1.0 References: <0853b4b0-770f-f742-95bc-eb74a1859138@quicinc.com> In-Reply-To: <0853b4b0-770f-f742-95bc-eb74a1859138@quicinc.com> From: Frank van der Linden Date: Fri, 14 Apr 2023 15:02:17 -0700 Message-ID: Subject: Re: [PATCH V7 0/2] mm: shmem: support POSIX_FADV_[WILL|DONT]NEED for shmem files To: Charan Teja Kalla Cc: akpm@linux-foundation.org, hughd@google.com, willy@infradead.org, markhemm@googlemail.com, rientjes@google.com, surenb@google.com, shakeelb@google.com, quic_pkondeti@quicinc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: noyhwts37te14tegss911bmxk1ex33fw X-Rspamd-Queue-Id: 7747CC0030 X-HE-Tag: 1681509750-187673 X-HE-Meta: U2FsdGVkX1+SlvKN4F5pFlw5TPTCSgeQ8VsEK435FbbMdTGjrLlEqxMjbtWn5TlZtMGcKoGLH5XX9NOiS+fO7dXsmv+lDS0JpxyrJnZW4OhOlFDPcrjk9JLeq821mJKUOCeFpNl4vb4mB59SbKW93CiCU4b/21lTc6vsMuDxV5knm3o9JtZ0GYTdf3Z81CKsbUkbD+CULQslr7qKgkMdT00YWi34Xbttc0GFfbzY5nKk2yS8lAeDAzdM0JaoHnkhqoQ2+GVWbPs8WIlK1pi+y2DoDck3bK/ET1aWHFwChLGFsrto3IW7aXfoPlmJcMGyyZ+0OLVzWkaWgVbFejto8a/AHr9bGchN7jieqHMCf/IXuYzy/BEAlQ5S6ZzXJWaHfJ89iN/5dxktYP8bHtODH90MFvVb7Zl/ZmQgoaSRoX2avEhLfFnaXab89yQvEw/dgpyl9079Hd5a6/tYA1lvkWEK/XPU01wzhxE5tqGgB/NCo9SWYHJrKx7V3fpYRTQpy1xDEXHwXxK8J//exh3Qp0ObsYBfCFnUXw77KyRfsKJygDK1M5lb3pfPXjjogI1t82kDriteXkM0df0btlhi2UIMulCACiZoT0XnsoaOZfwyObk3uGY0oOPbR0YZRABvYlrmFDnE68kMTEAwd/X71QyEs7EOAkZYbs1or5YrbyU357hN6DyTOqqE6FZn/saITPsP3EfH+jSOvJdM6GFduQj5OihybNvheVw+0Nhx2gvdCcxfUPScm9utXaBj7btraaooSJu+dOXDNaRARE06XVNOpcHdUVqK6FIY+anxLObM5rhoc8+uxQEhXQ2dwpoh27UIsgMqL2HlQTlGR1l9SA5PL849cFqequHpMf9KmltU4TbP/7wqu0lXW2TqIk7v/q2/SmLNFa1OLyULWBfrW3kBy7wXdoYbGJxoMepUq8Ecd9yTK7ta6W6L56e6oxBHWs0QtsK9dTJOhBsOkzE CaW4HOvP 97aiJWXQ73q4MiLWblL6H5Ad/1pQ+LxW21YqE8EoeMfShY38ZtTJrOO3FgUbhRsPK8i2stOplg9j8imSijrJEzCErp5I7lpveSZumw/DQjtRltyVn0I7PdjCcWxYRZ5FqAIh9Xkxx1JRHG/IzR8aenjZs67Us8Yt28Bkt0/4NuGDhOUstO2VnMmpIAnn1/h4X7DHFRWG+te5e1yQCnvGlby9gYEYCgnYyZB8D33uvafdt1y0lugFsWqM4f5ZxNw9Lw2Qi3SLTzUNaBGhvcb5OQjAGrxpSxy/aVWsZ1XLJdHwKCTkD6lPxjPPpvXcGB8rOFQi78ozBW6lJHQSVhL96UBUN6wCUoN1wLI4Z X-Bogosity: Ham, tests=bogofilter, spamicity=0.000350, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 14, 2023 at 12:10=E2=80=AFPM Charan Teja Kalla wrote: > > Thanks Frank!! > > On 4/14/2023 11:14 PM, Frank van der Linden wrote: > >> I didn't see this patch before, so I looked a bit at the history. At > >> some point, in v3, dealing with mapped pages for DONTNEED was left > >> out, they are now skipped. Unfortunately, that makes this patch no > >> longer usable for a case that we have: restoring the (approximate) > >> swap state of a tmpfs file. This involves walking a potentially large > >> number of regions, and explicitly pushing them out to swap. This can > >> be used to e.g. restore the state VM memory that is backed by a tmpfs > >> file, avoiding memory usage by cold VM pages after resume. > >> > > This is an interesting use case and I feel this really supports this > patchset. IIUC, supporting the reclaim of mapped file pages through > fadvise() helps this usecase where you can avoid traversing the large > number of vma regions as you can directly issue the fadvise() on the > shmem file 'fd' and it takes care. Am I correct? Right, that's correct. The only snag here is that fadvise, with your patch set, will skip mapped pages, which might be an issue for this case. > > > Hmm, actually, looking at it a bit more, there are several issues > > here. One is that with fadvise, you can't be sure if you are the only > > one dealing with the page in a mapped way(with madvise, if mapcount =3D= =3D > > 1, that mean's it's just you, but you don't know that for fadvise, so > > that makes correctly dealing with mapped pages harder). > > > Sorry, Why not for fadvise()? I can still attempt only if the page is > mapped and its mapcount =3D=3D 1, but then we already have madvise() for > such pages and why not we simply use it. Yes, you could use madvise (as I was thinking). One issue with that is, though, that madvise(PAGEOUT) is based on a page table walk of present PTEs. So you actually need to map and touch the page before madvise will work, which is suboptimal. A direct fadvise solution would be nicer, since that does a file mapping walk. However, that can be addressed later, my comments weren't intended to raise an objection - merely that there is a chance here to address this usecase. But that shouldn't block anything. It's something to keep in mind, though. I'll do some experiments to see what the best solution is here. But, any follow-ups would be on top of your patch, so I'm not raising objections, merely hoping that this, and possible extra work, could solve this case. - Frank