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 63BF9C433EF for ; Mon, 6 Dec 2021 07:29:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7DDE6B007B; Mon, 6 Dec 2021 02:29:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C2D4D6B007D; Mon, 6 Dec 2021 02:29:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF4E46B007E; Mon, 6 Dec 2021 02:29:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id 9D4D56B007B for ; Mon, 6 Dec 2021 02:29:26 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5E96B8955A for ; Mon, 6 Dec 2021 07:29:16 +0000 (UTC) X-FDA: 78886543512.26.775134F Received: from m43-7.mailgun.net (m43-7.mailgun.net [69.72.43.7]) by imf04.hostedemail.com (Postfix) with ESMTP id DA0B140003 for ; Mon, 6 Dec 2021 07:29:15 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1638775755; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: From: References: Cc: To: Subject: Sender; bh=kpfkrbWxq3M3VkqCiFgC+HQj86saJq/Wq6k82Z/2x2s=; b=nuItm06XGIlMGhDW14Krbu5yMA2qukshn1z1jTPc+qt58SJuXoMbgWUl7ngIoCb2nWZxGeFr H7zAcbtmAAuh2l0S8Lo1UV95+ybPxqoCATAyNHKkYnu2CsrX8VaUvixKfLrJyCKHA2Km5O3O akdVNi8tT8zG418dCrUUFFguiG4= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyIwY2Q3OCIsICJsaW51eC1tbUBrdmFjay5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n01.prod.us-east-1.postgun.com with SMTP id 61adbbca642caac3188c7721 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 06 Dec 2021 07:29:14 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 3C827C43617; Mon, 6 Dec 2021 07:29:14 +0000 (UTC) Received: from [192.168.29.110] (unknown [49.37.157.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: charante) by smtp.codeaurora.org (Postfix) with ESMTPSA id 247D1C4338F; Mon, 6 Dec 2021 07:29:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.codeaurora.org 247D1C4338F Subject: Re: [PATCH v2] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem To: Shakeel Butt , Charan Teja Reddy Cc: hughd@google.com, akpm@linux-foundation.org, vbabka@suse.cz, rientjes@google.com, david@redhat.com, mhocko@suse.com, surenb@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1638442253-1591-1-git-send-email-quic_charante@quicinc.com> From: Charan Teja Kalla Message-ID: <4a5cde83-c673-6af0-702f-f8b59e05a397@codeaurora.org> Date: Mon, 6 Dec 2021 12:59:06 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: DA0B140003 X-Stat-Signature: czyykmeb8tbws5kxiznjr34cjn8y6dkx Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=mg.codeaurora.org header.s=smtp header.b=nuItm06X; spf=pass (imf04.hostedemail.com: domain of "bounce+d06763.be9e4a-linux-mm=kvack.org@mg.codeaurora.org" designates 69.72.43.7 as permitted sender) smtp.mailfrom="bounce+d06763.be9e4a-linux-mm=kvack.org@mg.codeaurora.org"; dmarc=none X-HE-Tag: 1638775755-448397 X-Bogosity: Ham, tests=bogofilter, spamicity=0.002437, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Thanks Shakeel for your valuable inputs!! On 12/2/2021 11:24 PM, Shakeel Butt wrote: > On Thu, Dec 2, 2021 at 2:51 AM Charan Teja Reddy > wrote: >> >> From: Charan Teja Reddy >> >> Currently fadvise(2) is supported only for the files that doesn't >> associated with noop_backing_dev_info thus for the files, like shmem, >> fadvise results into NOP. But then there is file_operations->fadvise() >> that lets the file systems to implement their own fadvise >> implementation. Use this support to implement some of the POSIX_FADV_XXX >> functionality for shmem files. >> >> This patch aims to implement POSIX_FADV_WILLNEED and POSIX_FADV_DONTNEED >> advices to shmem files which can be helpful for the drivers who may want >> to manage the shmem pages of the files that are created through >> shmem_file_setup[_with_mnt](). An example usecase may be like, driver >> can create the shmem file of the size equal to its requirements and >> map the pages for DMA and then pass the fd to user. The user who knows >> well about the usage of these pages can now decide when these pages are >> not required push them to swap through DONTNEED thus free up memory well >> in advance rather than relying on the reclaim and use WILLNEED when it >> decide that they are useful in the near future. IOW, it lets the clients >> to free up/read the memory when it wants to. Another usecase is that GEM >> objets which are currenlty allocated and managed through shmem files can >> use vfs_fadvise(DONT|WILLNEED) on shmem fd when the driver comes to >> know(like through some hints from user space) that GEM objects are not >> going to use/will need in the near future. > > The proposed semantics of POSIX_FADV_DONTNEED is actually similar to > MADV_PAGEOUT and different from MADV_DONTNEED. This is a user facing > API and this difference will cause confusion. man pages [1] says that "POSIX_FADV_DONTNEED attempts to free cached pages associated with the specified region." This statement, IIUC, on issuing this FADV, it is expected to free the file cache pages. And it is implementation defined If the dirty pages may be attempted to writeback. And the unwritten dirty pages will not be freed. And thus for Shmem files this is being done by dirtying the page and pushing out to swap. So, Isn't the FADV_DONTNEED also covers the semantics of MADV_PAGEOUT for file pages? IOW, what is the purpose of PAGEOUT for the file pages. Or I am missing some trivial logic in your comment here? Coming to MADV_DONTNEED[2], on the mapped shmem files doesn't have any effect as the pages of those shmem files can still be in RAM. Subsequent accesses of pages in the range will succeed from the up-to-date contents of the underlying mapped file. IOW, the pages are still be present in the cache. Am I wrong here? [1] https://man7.org/linux/man-pages/man2/posix_fadvise.2.html [2] https://man7.org/linux/man-pages/man2/madvise.2.html > -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project