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 757F8C761A6 for ; Thu, 6 Apr 2023 23:44:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBDCE6B0071; Thu, 6 Apr 2023 19:44:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6D1B6B0074; Thu, 6 Apr 2023 19:44:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5BD16B0075; Thu, 6 Apr 2023 19:44:38 -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 B790F6B0071 for ; Thu, 6 Apr 2023 19:44:38 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 884E780789 for ; Thu, 6 Apr 2023 23:44:38 +0000 (UTC) X-FDA: 80652598236.08.4BDE176 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf14.hostedemail.com (Postfix) with ESMTP id AAAF8100009 for ; Thu, 6 Apr 2023 23:44:36 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NowLn9YB; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf14.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680824676; h=from:from:sender: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=hM5yP2pQ2NYPi6a+BhVoXAxnw5yjpnbyF9Bo/kTEiDk=; b=jU210Ikavcu02S6/fkHuS2Qqrt+FKrhxgHV2FL1VS6OJJwsN/0CqxOF3jgz9JI8F4D2+6Y F7L534yUpg1OQKNgqKH4r+x3Te/g5eTSgtq6uJT3QgyRXLDpf98nd4rHnFVXunpN1T1Ufr wC44cfqYdAVcZy7j8dcM9bBado3bqbw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NowLn9YB; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf14.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680824676; a=rsa-sha256; cv=none; b=WpTt5l0JfJtGtYBKzekX1L0X7wXQ23G2wVgwtuCrrL2efVnJRH3Pf1QNA5PV0Qb0lWSQHM PYu2y6JTT087BNxe7CWIjewT/psLzJnUNUCzzRoV6t10R4b/LbnK6tKtTf3U0FOVBreIpi kpvSk2MrrUjNGGV+4rpQv13YB3cJObo= Received: by mail-pj1-f51.google.com with SMTP id go23so584609pjb.4 for ; Thu, 06 Apr 2023 16:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680824675; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=hM5yP2pQ2NYPi6a+BhVoXAxnw5yjpnbyF9Bo/kTEiDk=; b=NowLn9YBZM92Cp2OL5BmFlN9nwYVbhKaDMqG/Opl98f5kJFZ5sXo2v/Edo1DAC4o9a i6R7W5yuOoxF2wzBMVTYpJWlKO0stRMEG6NkXheFwz7TjS/ewsm1KKduXKi7kioAdkg4 msEuo/UZ220uvMQc5Wkm9Mp5gP5BWtApfT39LWfuNhvA+wRRCcnKQoVzWseHvDT2Ip+w szzIQKeGI9flnnH2LHAQowsq2vJHpZY28hkU3+Ei8EmgiHspiKxB9wAKZbO5O/uqdNUX 0yiFWTyny/KcdRwj+kd0UZxivX/6ddaMGnBYiIvrSEWtAOSodpV4M/qjRzcHxBCjN6Gu mW0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680824675; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hM5yP2pQ2NYPi6a+BhVoXAxnw5yjpnbyF9Bo/kTEiDk=; b=5uJssT+H0hP2aLMmEOsR5wnBq4Imyh8PeIz98OIR5RSM1x2nYSRLcHXwwl4y+1nlwr ReDjo56g2w7DC5FQ4XZjBMoumyqUPAV7BUXIE+6ti82aVQE4DDBvK3N6WEvtrcZjaSZT kK8V6nX0IbPE+zLurc2T9nz4C8qMe/AUdJrQS7MF9oZhTUQR/aPkzt2r0QAjR9Kg9JvU JEBpCjDyYWYhwBNrIAQLghD8xel8kANkBLAzwAd0azBGOMhyeyXN8j0mWovsOnEaHjOf 8JdKOazwE62Fs1zpA6SRv3yFpefRaAiOMu/G5YSipj2QBNtFXMcWdJSfMevm1nfPqQLw Iu8g== X-Gm-Message-State: AAQBX9e5byAop/MEM0KnPYcYVEKoSiJONBnK+4ZrUUiNtpEfwJhYpRs2 sFW+ahip+kRRhQhPDz0xYbMAh0CKbK8= X-Google-Smtp-Source: AKy350YRhZDeCWKl13JSZFKjtkuk1LnkcWSoeniRa4MoFv/lhHeS/ZsEbV1z3/R80ckYKT8TscvQZQ== X-Received: by 2002:a05:6a20:4918:b0:de:807e:620e with SMTP id ft24-20020a056a20491800b000de807e620emr916525pzb.58.1680824675582; Thu, 06 Apr 2023 16:44:35 -0700 (PDT) Received: from google.com ([2620:15c:211:201:6a8d:6a82:8d0e:6dc8]) by smtp.gmail.com with ESMTPSA id c17-20020a62e811000000b0062d9ced3db3sm1863836pfi.23.2023.04.06.16.44.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Apr 2023 16:44:34 -0700 (PDT) Date: Thu, 6 Apr 2023 16:44:32 -0700 From: Minchan Kim 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 Subject: Re: [PATCH V7 2/2] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem Message-ID: References: <631e42b6dffdcc4b4b24f5be715c37f78bf903db.1676378702.git.quic_charante@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <631e42b6dffdcc4b4b24f5be715c37f78bf903db.1676378702.git.quic_charante@quicinc.com> X-Rspamd-Queue-Id: AAAF8100009 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: da5hn3njbacpy6qj5awfz1gimn3u7ri6 X-HE-Tag: 1680824676-307787 X-HE-Meta: U2FsdGVkX19MwSvDTByp3OZAESOh2DBrwH3JzVqFstpy0fP/YocScUdbe16VytFO2caY1bfxkMyjSd+BWRsv+69nvXwrfbiJgymecQdwIvFWWuLy0M5puM4b1T15MFti1ZUzcwYL8Bmn2trGrj95eENealXGmMP1AyyZmjxWbGBFB9GcKRbU5vwitslJgK34kdRC5lHQsw4/2AG8wIypGHTpRfMDvV4T254/ppaQ/NZjRitOWvdKs2KX3utxIXHGEH0UKJn5ijeNFTDXBEy0T6H5h6fDlEvObpEMfZ0jSrU6/7/SiCxcderN5ClG1nOVGVmDPOTPmVQCfhXDQ55jDHZhk5f8t+jzIJCJZvN9UdJXEPV7zLWnMTc8Pc3srkuJc/zDcCbq7DfkgGoj0cPh8cF5zg1tF6GeUi8crvkdk4mPyhx+YQmXseTJqx/XmXbyrKm3gX9hEStJW2SVTUt8uy3AvxUqKl9qt3wcHUmRQ/rDRMVGnEcywJ4IzvnPjmB4DY8dUlWxaB7Joad4Px0VJ9xgfL34Rl22WgHLmM9GdPVYHS2GLqvW9ggQZJLaD0EPkwCbQJkJyHO2eGXZf6BjxwCqIHK37CgHlXQo1NBtnYoDKAV9G+lrNYpr+cZqjrqqIaeMBKLa4Uv99St9w26JnDErGA3aY7UbkWxv0jKubXxJmkDB8DRXcP63OmgAVqH+6omNCbHRTcPx+cV8XMlJ8ctNqaf5CR89b9nm+5IwgF3KauAgw8V1rduAIaND/WWaWrYZL12EpNy9AzJaFxvNaXvnxATw9R1oR7xn2gx+qAtUCQg0ABJuOyLqTVC8owGlUPUTw4aaY/yhpU6I+w2eDC36rsmBHxAI3yJDqFstKtQrc5rgXaqkbv7zhzITON3hWivRvojo6Lc+rv2/1apUwJwazmIy0fmW0UB+whq5jB+33hr3rbtzDzl3cp8/DJyjfpi/KFhUckk0zDMcpOv Gl/PCVxm bhtTZInjMu53oAt64jCP4SvKRDW5zHlrfZGGesNaAZ2mrO9BQPDcyFCk8aIg7Ud98oa/PoDKYXnUpTcjcVulAnYDEdqcD31i3SjZ5P053+X1tR4JCYqE33tm9ZDCTjwU+TdryFRbv7DfAzmdB7Y8v/Ls1pCMQRvutZrjTrGJatM229/a8cQxyFEailg3rtvFLlqAMGKzs+LWtkLzDfNTE8QjX9iIQIFalFy12CPY0QUlMh3NL/+BqA3/hgxfQiETEIqc9dZcouFpfTXbL0fDWakZHZ1j/qTKHOBEAvV9ecWxSP+nElPpeJmp+X9j7V9BG2nZERVz4Ui3USkzKMUludPHkr3+oCNqcNp+CeBSDPWbz7gOwu4hprnF7QV5vNJYDL5C5ha0NhpWxXT61aaBMcr0FcU3JVcrfJC7FlIhmGmj0szn33wZ/rz7CTOibZpM89fBCg8RjN5SR+A1bUdpm/WxBbG9NsBeOO21VPcT3xrs5t5G5uFcQQLkdf99VWTU8/nWM0HpJATm5cDd7qQ9GnBFiXWDjb92/NXrBc382i5q8eBWIwvv7CRQlkkWsvBFF5J9930d8Vbio3bZ7ekuC2vGHOBWFQqZvtTGk4jd/2dS0+Lrp5auFE4LHcLh765TU4vST350Ln0meHFwRn4MbEd+t7QGPca/G6nv2sUnk7JOQc1rbgESbiF/WKUE9YIaCezeeXMP97o7yMLPUPHnJSbeQZdsba2LtMaZbE7CwsP6KqSm3JhlkDBFuX4LKWkyFCcYvTnwND5sEBKhdYwkGkyVwvnHqgQC0J1ZugeuviuN0DTFED43Hit3FVRecgbQq7d2sYCJ4hTgjPivZAHzN0UjUyQ9kj6lH2X3BQNOK8XvpBngJ7+IdrK7xfPl9vRURFTeQ7KYfsCp+HDaUFesH1/EFldTebe1II7/k8LTmC6YgQzYSj3P/RDWwori33HS5j1EO X-Bogosity: Ham, tests=bogofilter, spamicity=0.009982, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 14, 2023 at 06:21:50PM +0530, Charan Teja Kalla wrote: > 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 clients who may want > to manage the shmem pages of the files that are created through > shmem_file_setup[_with_mnt](). One usecase is implemented on the > Snapdragon SoC's running Android where the graphics client is allocating > lot of shmem pages per process and pinning them. When this process is > put to background, the instantaneous reclaim is performed on those shmem > pages using the logic implemented downstream[3][4]. With this patch, the > client can now issue the fadvise calls on the shmem files that does the > instantaneous reclaim which can aid the use cases like mentioned above. > > This usecase lead to ~2% reduction in average launch latencies of the > apps and 10% in total number of kills by the low memory killer running > on Android. > > Some questions asked while reviewing this patch: > Q) Can the same thing be achieved with FD mapped to user and use > madvise? > A) All drivers are not mapping all the shmem fd's to user space and want > to manage them with in the kernel. Ex: shmem memory can be mapped to the > other subsystems and they fill in the data and then give it to other > subsystem for further processing, where, the user mapping is not at all > required. A simple example, memory that is given for gpu subsystem > which can be filled directly and give to display subsystem. And the > respective drivers know well about when to keep that memory in ram or > swap based on may be a user activity. > > Q) Should we add the documentation section in Manual pages? > A) The man[1] pages for the fadvise() whatever says is also applicable > for shmem files. so couldn't feel it correct to add specific to shmem > files separately. > > Q) 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? > A) man pages [2] says that "POSIX_FADV_DONTNEED attempts to free cached > pages associated with the specified region." This means 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. So, FADV_DONTNEED also > covers the semantics of MADV_PAGEOUT for file pages and there is no > purpose of PAGEOUT for file pages. > > [1] https://linux.die.net/man/2/fadvise > [2] https://man7.org/linux/man-pages/man2/posix_fadvise.2.html > [3] https://git.codelinaro.org/clo/la/platform/vendor/qcom/opensource/graphics-kernel/-/blob/gfx-kernel.lnx.1.0.r3-rel/kgsl_reclaim.c#L289 > [4] https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10/mm/shmem.c#4310 > > Signed-off-by: Charan Teja Kalla I am not familar with why the shmem has noop_backing_dev_info but the below code to reclaim shmem pages and POXIS_FADV_DONTNEED semantic looks correct for me. Only nit is the description covers mostly DONTNEED case but not WILLNEED case.