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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH, USER_AGENT_MUTT 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 30CDEC04AB6 for ; Tue, 28 May 2019 10:41:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 06FE22081C for ; Tue, 28 May 2019 10:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559040081; bh=LGafzQ9FpsxScocufsydacEFOCrRaZmMjdc9PzAXkAI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=QHEXQeMvyCLbQcRjTzhaK+VRC6RELDkPkUFyMseJjd03V/PNwd1YvOlu0s+KTz0yN I2BvfhCaXbejVYPox8cOaI+lNxD7vPxO8H8P2Ius0JBDylyB4AEA08uTXL5IZIHFYm DI9sPh+YvI/zOgyOelLaGoVJvPfM/gxcS+UvadDM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726667AbfE1KlU (ORCPT ); Tue, 28 May 2019 06:41:20 -0400 Received: from mx2.suse.de ([195.135.220.15]:40384 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726334AbfE1KlU (ORCPT ); Tue, 28 May 2019 06:41:20 -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 E7A0CAEC8; Tue, 28 May 2019 10:41:18 +0000 (UTC) Date: Tue, 28 May 2019 12:41:17 +0200 From: Michal Hocko To: Minchan Kim Cc: Daniel Colascione , Andrew Morton , LKML , linux-mm , Johannes Weiner , Tim Murray , Joel Fernandes , Suren Baghdasaryan , Shakeel Butt , Sonny Rao , Brian Geffon , Linux API Subject: Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER Message-ID: <20190528104117.GW1658@dhcp22.suse.cz> References: <20190521062628.GE32329@dhcp22.suse.cz> <20190527075811.GC6879@google.com> <20190527124411.GC1658@dhcp22.suse.cz> <20190528032632.GF6879@google.com> <20190528062947.GL1658@dhcp22.suse.cz> <20190528081351.GA159710@google.com> <20190528084927.GB159710@google.com> <20190528090821.GU1658@dhcp22.suse.cz> <20190528103256.GA9199@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190528103256.GA9199@google.com> 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 Tue 28-05-19 19:32:56, Minchan Kim wrote: > On Tue, May 28, 2019 at 11:08:21AM +0200, Michal Hocko wrote: > > On Tue 28-05-19 17:49:27, Minchan Kim wrote: > > > On Tue, May 28, 2019 at 01:31:13AM -0700, Daniel Colascione wrote: > > > > On Tue, May 28, 2019 at 1:14 AM Minchan Kim wrote: > > > > > if we went with the per vma fd approach then you would get this > > > > > > feature automatically because map_files would refer to file backed > > > > > > mappings while map_anon could refer only to anonymous mappings. > > > > > > > > > > The reason to add such filter option is to avoid the parsing overhead > > > > > so map_anon wouldn't be helpful. > > > > > > > > Without chiming on whether the filter option is a good idea, I'd like > > > > to suggest that providing an efficient binary interfaces for pulling > > > > memory map information out of processes. Some single-system-call > > > > method for retrieving a binary snapshot of a process's address space > > > > complete with attributes (selectable, like statx?) for each VMA would > > > > reduce complexity and increase performance in a variety of areas, > > > > e.g., Android memory map debugging commands. > > > > > > I agree it's the best we can get *generally*. > > > Michal, any opinion? > > > > I am not really sure this is directly related. I think the primary > > question that we have to sort out first is whether we want to have > > the remote madvise call process or vma fd based. This is an important > > distinction wrt. usability. I have only seen pid vs. pidfd discussions > > so far unfortunately. > > With current usecase, it's per-process API with distinguishable anon/file > but thought it could be easily extended later for each address range > operation as userspace getting smarter with more information. Never design user API based on a single usecase, please. The "easily extended" part is by far not clear to me TBH. As I've already mentioned several times, the synchronization model has to be thought through carefuly before a remote process address range operation can be implemented. -- Michal Hocko SUSE Labs