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 498E0ECAAD4 for ; Fri, 26 Aug 2022 23:12:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7270940008; Fri, 26 Aug 2022 19:12:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A216C940007; Fri, 26 Aug 2022 19:12:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91077940008; Fri, 26 Aug 2022 19:12:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7DF91940007 for ; Fri, 26 Aug 2022 19:12:33 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4E7F612044A for ; Fri, 26 Aug 2022 23:12:33 +0000 (UTC) X-FDA: 79843294986.19.3D742CC Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf24.hostedemail.com (Postfix) with ESMTP id 07D2918001B for ; Fri, 26 Aug 2022 23:12:32 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id x19so2818614plc.5 for ; Fri, 26 Aug 2022 16:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc; bh=s4XMaSuzt0RupgqDZnotNYUz45F0tGFlfV0bB/SFY04=; b=XpheRnpwE+pPzZGqc2WFt0N5mwsQHRmamxSaM/3QvO1c70gJ9Stz0VIDfT1lzB9tvP yR3Mh2rfF7p8yPXwhw21MNoqYc4+d4dfU3OX5FfgbI8jaMwy8QvqGjJaMRUINh6YQMa3 Ctyw7EcC+wdH5mpwDUN/hSWN9E/d2Lt0OTI45rlQNlzwPHSFbbAn46CfQ8mNeY7gQgcm EwM3LpOPwz2w8cb6DbYYkGCAkemHKr+AzVsF8kQwnw/DXjok+xyERADfshd4pAE+tqiY s9G1mIqseWIw6t5m9g1PJk7HNy96Hu4ylcotms7zniJIKqsg2loA7HB4xyx6ZMIRGPLG 9T3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc; bh=s4XMaSuzt0RupgqDZnotNYUz45F0tGFlfV0bB/SFY04=; b=Juq/nx/swi2YWXoYolQ2L5pSc3nwLeYqXKySud5/3cPUgrYDN1Mjnp7/ioKhwBJerY P/9o3yPjbYMcELbTsH0Dt7zZ2rQurA1vRecrk4R5lf5wSWMXLbNCQoT64+WLpsRGJEnZ eWjGZDu05HvQg1TQKyMvNXZ3a1BSvTxhLAjvJVBep+xtSqRVpI4IVqiV9UJtCLoP/PXD ZIU9OFe56SioCC09txqql3o4cnL6RYJNnZf6sVluV1W5gB+X21uOYMXI1h1AqQmtzEY1 3/d4eaLRp622v1RWDzwAw7dJ0g6ZCruKPTRIplovyXik84tZKubJnjvsaWF0CBN+JyAm EXvQ== X-Gm-Message-State: ACgBeo1m3ljvhVz2Mx5olPjvwhB22b9p8WbD9WXKgAbPqPMUD5ApPxEJ 5sfRNeD70xwDSSv17pSTsXM= X-Google-Smtp-Source: AA6agR7mogKBQ8ZTyRsP3rC4Je/te/ppp3/qoRFpqKImUtgmAIyMlW0B5SVzui2BwqL8YnxncG3C8Q== X-Received: by 2002:a17:902:e892:b0:174:4022:b9c8 with SMTP id w18-20020a170902e89200b001744022b9c8mr3808435plg.0.1661555551983; Fri, 26 Aug 2022 16:12:31 -0700 (PDT) Received: from google.com ([2620:15c:211:201:60eb:6401:167f:b157]) by smtp.gmail.com with ESMTPSA id q3-20020a63f943000000b0041c45d76b6bsm1956473pgk.38.2022.08.26.16.12.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Aug 2022 16:12:31 -0700 (PDT) Date: Fri, 26 Aug 2022 16:12:29 -0700 From: Minchan Kim To: Yang Shi Cc: Yu Zhao , Matthew Wilcox , "Yin, Fengwei" , Andrew Morton , Linux-MM , =?utf-8?B?6Z+p5aSp56GV?= , mawupeng Subject: Re: (resend)WARNING: trying to isolate tail page in isolate_lru_page Message-ID: References: <485f8c33.2471b.182d5726afb.Coremail.hantianshuo@iie.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661555553; a=rsa-sha256; cv=none; b=A5oydqYSxLVdHoebrQT46PYtnRUBt6sUAZLiaQ3Rpjek3CGzRFrDX/nEUdDsOwc6XDaEoP 9/SmVTrVXzVDI0d941UXjZFDXJx3sBQSyf4vtJ2xx+jOBIAGouQG6mJWb7CijucPlvQQ/L j530kTS1rydE43uqi6Tqc/4tmlh/NRk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=XpheRnpw; spf=pass (imf24.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661555553; 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=s4XMaSuzt0RupgqDZnotNYUz45F0tGFlfV0bB/SFY04=; b=KpkhcgsH9izamaoIcEkPrXwVSFI+uscK4GjGGI53KIlw0pn+6ySO2+PkxNkcotcvLuvK+X vT/fXYxn/47wOa09OBu7NdkSVPUxFAo4kgKDktIsgqGqEU0BxVx/tGJfEJEPwmS/DYLx/O 5CLAkMRTWzLSiv4OXS8sndxFYMB0SnE= X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=XpheRnpw; spf=pass (imf24.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Rspamd-Server: rspam08 X-Stat-Signature: 3k65cfhwj3kzzuo4m7qah99s8kcucstn X-Rspamd-Queue-Id: 07D2918001B X-HE-Tag: 1661555552-99472 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 26, 2022 at 11:19:37AM -0700, Yang Shi wrote: > On Fri, Aug 26, 2022 at 10:53 AM Minchan Kim wrote: > > > > On Fri, Aug 26, 2022 at 11:27:53AM -0600, Yu Zhao wrote: > > > On Fri, Aug 26, 2022 at 11:15 AM Matthew Wilcox wrote: > > > > > > > > On Fri, Aug 26, 2022 at 11:20:58AM +0800, Yin, Fengwei wrote: > > > > > On 8/26/2022 2:46 AM, Matthew Wilcox wrote: > > > > > > There's a number of ways of solving this. I'm interested in seeing > > > > > > which one Minchan thinks is best. > > > > > > > > > > My understanding is: > > > > > PageTransCompound() return false for compound page if THP is disabled > > > > > in kernel config. Replacing PageTransCompound() with PageCompound() > > > > > could work here. But for the long term, folio should be the answer. :). > > > > > > > > Yes, ultimately, isolate_lru_page() is going away as an interface > > > > and one will have to call folio_isolate_lru(). But should > > > > madvise_cold_or_pageout_pte_range() even be getting called for VMAs > > > > which are mmaps of af_packet? can_madv_lru_vma() rules out a number > > > > of different types of VMA; should it also be ruling out af_packet VMAs? > > > > > > Agreed. > > > > > > > If so, how? > > > > > > We should add a reliable helper to tell whether a file VMA is > > > reclaimable or not. I don't think we have one. Currently MGLRU checks > > > mapping->a_ops->read_folio for file VMAs to determine whether they are > > > reclaimable. > > > > > > > Long term, that's better idea(For stable backport, I'd like to go with > > simple PageLRU check). > > > > I wonder it's possible to mix LRU pages and non-struct pages together > > in a VMA. Otherwise, could we reuse(abuse) VM_MIXEDMAP? > > I don't think the mix is going to happen via regular mmap call. At a quick glance of vm_insert_page, it could change vm_flags into VM_MIXEDMAP dynamically. I am worry that a driver may call the vm_insert_page in the vma which already has LRU pages before so the VMA could have both LRU pages and non-LRU pages in the VMA. If it's doable, we may miss LRU pages if we filter VM_MIXEDMAP out in can_madv_lru_vma. Not sure it's common case. Otherwise, yeah, we may introduce a new vm_flag, something like, VM_NON_LRU. Just thought.