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 X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 746EDC31E40 for ; Tue, 6 Aug 2019 11:14:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2E56A20B1F for ; Tue, 6 Aug 2019 11:14:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="KPa6QKnx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E56A20B1F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=joelfernandes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A8D856B000D; Tue, 6 Aug 2019 07:14:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3E146B000E; Tue, 6 Aug 2019 07:14:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92CF56B0010; Tue, 6 Aug 2019 07:14:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id 5E2186B000D for ; Tue, 6 Aug 2019 07:14:50 -0400 (EDT) Received: by mail-pf1-f199.google.com with SMTP id e20so55703325pfd.3 for ; Tue, 06 Aug 2019 04:14:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:date:from:to:cc:subject :message-id:references:mime-version:content-disposition:in-reply-to :user-agent; bh=KvkNmNHsbEsshqDq0R83F3R8IDaL+JW1sWF+nvR0WDc=; b=LMS45erX+yk2ACXMD6n8tT7v/ZF2QfmWWsgvQiBAJ/mPW9es8vLZnzSlEau7f7bmnz NjlPUrl2wTSVCiQivRPWfeTJYzYEW8ujSzxZYP5Xu9uvvkcdwJhWtxzP53mPK59GWH6k ye7KHWYGUbnXnSMxsRVcqSdBmKW5KJlHfnnJgunnGXCfmyaPsO+maZiUfkjhRiQgQir4 X7PV7Kh+MMCyfEWsIzydF/3lMNU5vVKJmAszwJzwwHslagrDSs2YhuNoUoOBSoeaFA9d DwmeelLzcPczPlpJPlm//p8BdCcycvLxwNg5saZnI5T0nVJnsQ4rVXDu+dP3Nq7+67sc iwaA== X-Gm-Message-State: APjAAAXOjtdBEX+Mf6zphpDR+cP2SthDWdwJ5HmRz3V4e7MsuzojNhM4 yacJKApooVY1afHhfRvhAGRZMuEnOwA+EuLES5diC52h5NWBnKTNZLkB1YBPYaGSZTiHEX4Wpsv CTiAiFX6GH7SloADlV74sprlA+5GDJJDuhja7zDgrH17UU/vNHtnDSDB9hayhLoMHXA== X-Received: by 2002:a17:902:b70c:: with SMTP id d12mr2564044pls.314.1565090090067; Tue, 06 Aug 2019 04:14:50 -0700 (PDT) X-Received: by 2002:a17:902:b70c:: with SMTP id d12mr2564000pls.314.1565090089359; Tue, 06 Aug 2019 04:14:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565090089; cv=none; d=google.com; s=arc-20160816; b=Elgt7SeeBgNEnEI4ZazKiK5Pen3S9B2JnQoLB242zCXRaKZpctKmJITk7XoIoZV0o0 0SIo3Q71SR7qmfd+e2rSJEXN9d0YpsCAsclnHYLfkes4HjKrP1dpQz3jo8LUhCN9ZI9w qPHoU8EluQQVFD2J8D07KH3bZ5ShUungfPrZTrwdOohPa9qq6PrtnFIQsh9c2D4sq934 BirFf7fRgP1oxtb5+z2uSgiqJrUPDcHjS9AQlFpuBRphpHIGege63RrgiAcwByZG+B5I J12NTrb/BgWgjA+k1XS71+MnySy5FANCkdXz+r0XIHgnRj7BGLTypD7BNAUbwwrArxVK DQEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:dkim-signature; bh=KvkNmNHsbEsshqDq0R83F3R8IDaL+JW1sWF+nvR0WDc=; b=nT71p3Zd+cH4qDaMu7y6uz/qo1IHHjSGAOHH0amKzjEEV6Tj70Isg9ThkZr83ih2N/ ELnTSpkXpKUAdi65jk0C8+Sd6vSSy7viBkJwUCuORmLKSIJ9DtgSLW3HnQfQZbPmopv3 lq4X8TBjh70/jGBBO0E9exBYupq/Vwb1RtUrXGqseEc0RXWRhd57IHA2lSCBxW91WIeV flUrxlz1LGXwggsg5qyR6fULSYZDrF8or7r03UPxkVwn5XAn9Gvn/ah1oCdd5u4SLPca LyGnfcT2ed+tWXU9atINhPG7eY6AHHCFDauWZYJcUErbGALxUm0g4EnSGQoIsdxgcJsR e6Ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=KPa6QKnx; spf=pass (google.com: domain of joel@joelfernandes.org designates 209.85.220.65 as permitted sender) smtp.mailfrom=joel@joelfernandes.org Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id l64sor60306909pgd.60.2019.08.06.04.14.49 for (Google Transport Security); Tue, 06 Aug 2019 04:14:49 -0700 (PDT) Received-SPF: pass (google.com: domain of joel@joelfernandes.org designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=KPa6QKnx; spf=pass (google.com: domain of joel@joelfernandes.org designates 209.85.220.65 as permitted sender) smtp.mailfrom=joel@joelfernandes.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KvkNmNHsbEsshqDq0R83F3R8IDaL+JW1sWF+nvR0WDc=; b=KPa6QKnxrNTQGpt5Be94ogXIM0tXRuHNl0Aci8ksuKqx+9Lg0NCMbyYGZ0PixtmM1F 9+/1CJaHeIjkQbsXxRId0/VfGyWslK1AzTbonPe21m7278Ic8LGGTroo8d6GKLHYwRIn kQu/hhkwu4/wt6irUWyPejLfppauPTVejq9Ns= X-Google-Smtp-Source: APXvYqy6yyBYEGtjUPHZ5dr0UVaP823zcPxj13PdfdTPtKDAgMLJjNwSEplUX7wpUqySjdepMyEjAg== X-Received: by 2002:a63:1749:: with SMTP id 9mr2661368pgx.0.1565090088827; Tue, 06 Aug 2019 04:14:48 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id z13sm87648050pfa.94.2019.08.06.04.14.47 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 06 Aug 2019 04:14:47 -0700 (PDT) Date: Tue, 6 Aug 2019 07:14:46 -0400 From: Joel Fernandes To: Michal Hocko Cc: linux-kernel@vger.kernel.org, Robin Murphy , Alexey Dobriyan , Andrew Morton , Borislav Petkov , Brendan Gregg , Catalin Marinas , Christian Hansen , dancol@google.com, fmayer@google.com, "H. Peter Anvin" , Ingo Molnar , Jonathan Corbet , Kees Cook , kernel-team@android.com, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport , minchan@kernel.org, namhyung@google.com, paulmck@linux.ibm.com, Roman Gushchin , Stephen Rothwell , surenb@google.com, Thomas Gleixner , tkjos@google.com, Vladimir Davydov , Vlastimil Babka , Will Deacon Subject: Re: [PATCH v4 3/5] [RFC] arm64: Add support for idle bit in swap PTE Message-ID: <20190806111446.GA117316@google.com> References: <20190805170451.26009-1-joel@joelfernandes.org> <20190805170451.26009-3-joel@joelfernandes.org> <20190806084203.GJ11812@dhcp22.suse.cz> <20190806103627.GA218260@google.com> <20190806104755.GR11812@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190806104755.GR11812@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote: > On Tue 06-08-19 06:36:27, Joel Fernandes wrote: > > On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote: > > > On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote: > > > > This bit will be used by idle page tracking code to correctly identify > > > > if a page that was swapped out was idle before it got swapped out. > > > > Without this PTE bit, we lose information about if a page is idle or not > > > > since the page frame gets unmapped. > > > > > > And why do we need that? Why cannot we simply assume all swapped out > > > pages to be idle? They were certainly idle enough to be reclaimed, > > > right? Or what does idle actualy mean here? > > > > Yes, but other than swapping, in Android a page can be forced to be swapped > > out as well using the new hints that Minchan is adding? > > Yes and that is effectivelly making them idle, no? That depends on how you think of it. If you are thinking of a monitoring process like a heap profiler, then from the heap profiler's (that only cares about the process it is monitoring) perspective it will look extremely odd if pages that are recently accessed by the process appear to be idle which would falsely look like those processes are leaking memory. The reality being, Android forced those pages into swap because of other reasons. I would like for the swapping mechanism, whether forced swapping or memory reclaim, not to interfere with the idle detection. This is just an effort to make the idle tracking a little bit better. We would like to not lose the 'accessed' information of the pages. Initially, I had proposed what you are suggesting as well however the above reasons made me to do it like this. Also Minchan and Konstantin suggested this, so there are more people interested in the swap idle bit. Minchan, can you provide more thoughts here? (He is on 2-week vacation from today so hopefully replies before he vanishes ;-)). Also assuming all swap pages as idle has other "semantic" issues. It is quite odd if a swapped page is automatically marked as idle without userspace telling it to. Consider the following set of events: 1. Userspace marks only a certain memory region as idle. 2. Userspace reads back the bits corresponding to a bigger region. Part of this bigger region is swapped. Userspace expects all of the pages it did not mark, to have idle bit set to '0' because it never marked them as idle. However if it is now surprised by what it read back (not all '0' read back). Since a page is swapped, it will be now marked "automatically" as idle as per your proposal, even if userspace never marked it explicity before. This would be quite confusing/ambiguous. I will include this and other information in future commit messages. thanks, - Joel