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=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 70839C433FF for ; Tue, 6 Aug 2019 08:56:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 434942070D for ; Tue, 6 Aug 2019 08:56:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565081771; bh=2yIjMMpg8WPcVt8CXyEAoJ5EygheeLFNm3p7hsnCOvM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=J6Ena3cK2UgZo71Yee0BbIT4W5CLnOtrOih74T9MIFrvqrf7136ikx8vZ77vp+LPd cYbFUE+jTcZ4qFUS7VYwqeBl2gUfUsO/itGvDzfW3ag+Wa3sKJX56ktTXFKXKkQgr5 W3lWde8fSUi37MmyUp3A5JMgMFOkRBRfoUBF1V70= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732381AbfHFI4K (ORCPT ); Tue, 6 Aug 2019 04:56:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:36676 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726713AbfHFI4K (ORCPT ); Tue, 6 Aug 2019 04:56:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 86300ACA0; Tue, 6 Aug 2019 08:56:08 +0000 (UTC) Date: Tue, 6 Aug 2019 10:56:05 +0200 From: Michal Hocko To: "Joel Fernandes (Google)" Cc: linux-kernel@vger.kernel.org, Alexey Dobriyan , Andrew Morton , Borislav Petkov , Brendan Gregg , Catalin Marinas , Christian Hansen , dancol@google.com, fmayer@google.com, "H. Peter Anvin" , Ingo Molnar , joelaf@google.com, 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, Robin Murphy , Roman Gushchin , Stephen Rothwell , surenb@google.com, Thomas Gleixner , tkjos@google.com, Vladimir Davydov , Vlastimil Babka , Will Deacon Subject: Re: [PATCH v4 1/5] mm/page_idle: Add per-pid idle page tracking using virtual indexing Message-ID: <20190806085605.GL11812@dhcp22.suse.cz> References: <20190805170451.26009-1-joel@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190805170451.26009-1-joel@joelfernandes.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 05-08-19 13:04:47, Joel Fernandes (Google) wrote: > The page_idle tracking feature currently requires looking up the pagemap > for a process followed by interacting with /sys/kernel/mm/page_idle. > Looking up PFN from pagemap in Android devices is not supported by > unprivileged process and requires SYS_ADMIN and gives 0 for the PFN. > > This patch adds support to directly interact with page_idle tracking at > the PID level by introducing a /proc//page_idle file. It follows > the exact same semantics as the global /sys/kernel/mm/page_idle, but now > looking up PFN through pagemap is not needed since the interface uses > virtual frame numbers, and at the same time also does not require > SYS_ADMIN. > > In Android, we are using this for the heap profiler (heapprofd) which > profiles and pin points code paths which allocates and leaves memory > idle for long periods of time. This method solves the security issue > with userspace learning the PFN, and while at it is also shown to yield > better results than the pagemap lookup, the theory being that the window > where the address space can change is reduced by eliminating the > intermediate pagemap look up stage. In virtual address indexing, the > process's mmap_sem is held for the duration of the access. As already mentioned in one of the previous versions. The interface seems sane and the usecase as well. So I do not really have high level objections. >From a quick look at the patch I would just object to pulling swap idle tracking into this patch because it makes the review harder and it is essentially a dead code until a later patch. I am also not sure whether that is really necessary and it really begs for an explicit justification. I will try to go through the patch more carefully later as time allows. > Signed-off-by: Joel Fernandes (Google) -- Michal Hocko SUSE Labs