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.5 required=3.0 tests=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 26353C2D0DB for ; Mon, 20 Jan 2020 15:44:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E6453217F4 for ; Mon, 20 Jan 2020 15:44:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6453217F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9465A6B067A; Mon, 20 Jan 2020 10:44:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F5296B067B; Mon, 20 Jan 2020 10:44:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BD8E6B067C; Mon, 20 Jan 2020 10:44:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0187.hostedemail.com [216.40.44.187]) by kanga.kvack.org (Postfix) with ESMTP id 66D576B067A for ; Mon, 20 Jan 2020 10:44:50 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 1DE26181AC9C6 for ; Mon, 20 Jan 2020 15:44:50 +0000 (UTC) X-FDA: 76398435540.08.dog34_d088b376e727 X-HE-Tag: dog34_d088b376e727 X-Filterd-Recvd-Size: 5680 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jan 2020 15:44:49 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id d139so180921wmd.0 for ; Mon, 20 Jan 2020 07:44:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JRmMzO219tY5iJKWdolr3waKgeawvzdw0ymvmaVvtNg=; b=k23nmK4x4esLrhOriD/CwXH3Pw64MkHR+ujeU0/nXqtuIxnnFCNCK5q5u/ILVakPTD 4ofqgJCoZRTwQF/1ydtW2E3CRaQnyp479FE47/0TtnKgOGWwsaaK0jHpdjf3w/eZYLZj E/fuyShExtYbpiHeq9lzX9mzyac9lg61OYraqaAjX+h/sHKAUWZST0d1DdadT3KbTtmJ 6pwI+LeaLZsXaw2FkHN/kDT2HCoUOh6vX+tAd6CouBt6thf/93EqGXs47LE/hRLRj6VW UsQwkiYTXQCDl1JbzkT0dWRVRl50sQW+UbrPxH4j9QCVFECARZfQaroXK6nq5u1GfP74 LTZg== X-Gm-Message-State: APjAAAWLBTWEi8Zbe/uepqDVPsxMJYHzATmDfc1u5U4CSSuyBLy4TL3C Eg+barZcQRwV2cFfAK691HA= X-Google-Smtp-Source: APXvYqzAIcLxEjmh3U3YLGcGTq8iaQY80TZAl/1LPfWmpjMPs4mLoPEkFXfSbbEY9QWlzESIg/1FRg== X-Received: by 2002:a1c:740b:: with SMTP id p11mr15320wmc.78.1579535088464; Mon, 20 Jan 2020 07:44:48 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id v3sm47734043wru.32.2020.01.20.07.44.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jan 2020 07:44:47 -0800 (PST) Date: Mon, 20 Jan 2020 16:44:47 +0100 From: Michal Hocko To: "Kirill A. Shutemov" Cc: Kirill Tkhai , Minchan Kim , Andrew Morton , LKML , linux-mm , linux-api@vger.kernel.org, oleksandr@redhat.com, Suren Baghdasaryan , Tim Murray , Daniel Colascione , Sandeep Patil , Sonny Rao , Brian Geffon , Johannes Weiner , Shakeel Butt , John Dias , christian.brauner@ubuntu.com, sjpark@amazon.de Subject: Re: [PATCH v2 2/5] mm: introduce external memory hinting API Message-ID: <20200120154447.GL18451@dhcp22.suse.cz> References: <20200116235953.163318-1-minchan@kernel.org> <20200116235953.163318-3-minchan@kernel.org> <20200117115225.GV19428@dhcp22.suse.cz> <20200120112722.GY18451@dhcp22.suse.cz> <20200120123935.onlls7enjtzenbvt@box> <20200120132405.GF18451@dhcp22.suse.cz> <20200120142132.srf4igph4zmecu7b@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200120142132.srf4igph4zmecu7b@box> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Mon 20-01-20 17:21:32, Kirill A. Shutemov wrote: > On Mon, Jan 20, 2020 at 02:24:05PM +0100, Michal Hocko wrote: > > On Mon 20-01-20 15:39:35, Kirill A. Shutemov wrote: > > > On Mon, Jan 20, 2020 at 12:27:22PM +0100, Michal Hocko wrote: > > > > On Mon 20-01-20 13:24:35, Kirill Tkhai wrote: > > [...] > > > > > Even two threads on common memory need a synchronization > > > > > to manage mappings in a sane way. Managing memory from two processes > > > > > is the same in principle, and the only difference is that another level > > > > > of synchronization is required. > > > > > > > > Well, not really. The operation might simply attempt to perform an > > > > operation on a specific memory area and get a failure if it doesn't > > > > reference the same object anymore. What I think we need is some form of > > > > a handle to operate on. In the past we have discussed several > > > > directions. I was proposing /proc/self/map_anon/ (analogous to > > > > map_files) where you could inspect anonymous memory and get a file > > > > handle for it. madvise would then operate on the fd and then there > > > > shouldn't be a real problem to revalidate that the object is still > > > > valid. But there was no general enthusiasm about that approach. There > > > > are likely some land mines on the way. > > > > > > Converting anon memory to file-backed is bad idea and going to backfire. > > > > I didn't mean to convert. I meant to expose that information via proc > > the same way we do for file backed mappings. That shouldn't really > > require to re-design the way how anonymous vma work IMO. But I haven't > > tried that so there might be many gotchas there. > > > > There are obvious things to think about though. Such fd cannot be sent > > to other processes (SCM stuff), mmap of the file would have to be > > disallowed and many others I am not aware of. I am not even pushing this > > direction because I am not convinced about how viable it is myself. But > > it would sound like a nice extension of the existing mechanism we have > > and a file based madvise sounds attractive to me as well because we > > already have that. > > If the fd cannot be passed around or mmaped what does it represent? Because it is a cookie maintained by the kernel. > And how is it different from plain address? Kernel can revalidate that the given fd is denoting the vma it was created for and simply fail with ENOENT or whatever suits if somebody did unmap and mmap to the same address. -- Michal Hocko SUSE Labs