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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 A3DB3CA9EC4 for ; Tue, 29 Oct 2019 08:56:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4D4AC2086A for ; Tue, 29 Oct 2019 08:56:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="bK6YBI1j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D4AC2086A 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 C6AB16B0005; Tue, 29 Oct 2019 04:56:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C1C2C6B0006; Tue, 29 Oct 2019 04:56:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B30E06B0007; Tue, 29 Oct 2019 04:56:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 8B0F76B0005 for ; Tue, 29 Oct 2019 04:56:04 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 217938E41 for ; Tue, 29 Oct 2019 08:56:04 +0000 (UTC) X-FDA: 76096215048.22.snake79_34e01a935e462 X-HE-Tag: snake79_34e01a935e462 X-Filterd-Recvd-Size: 3656 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Oct 2019 08:56:03 +0000 (UTC) Received: from rapoport-lnx (190.228.71.37.rev.sfr.net [37.71.228.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1031420663; Tue, 29 Oct 2019 08:55:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572339362; bh=RCMUTEieUAqbdDi3UXC44oJQHvnrbU2QZQPBK7vKBHo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bK6YBI1jHf1yer+gIAFBkdQfdkJZfxdS24Gvl3LhKuDLpEa8DWiPe8Sr+QPDFcRYj 4XIAV2Tn4t1Puqkg2rtTqMX+AKf6wJ6qNHzPTy7COE4QD0QxiWPoIiygzCaMPZVLSN 5WIqGWIJMAxMy0jB5tFSVt1yZ4+rFA618tmvoMTI= Date: Tue, 29 Oct 2019 09:55:53 +0100 From: Mike Rapoport To: Christopher Lameter Cc: "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, Alexey Dobriyan , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Dave Hansen , James Bottomley , Peter Zijlstra , Steven Rostedt , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , linux-api@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, Mike Rapoport Subject: Re: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings Message-ID: <20191029085551.GA18773@rapoport-lnx> References: <1572171452-7958-1-git-send-email-rppt@kernel.org> <1572171452-7958-2-git-send-email-rppt@kernel.org> <20191028123124.ogkk5ogjlamvwc2s@box> <20191028130018.GA7192@rapoport-lnx> <20191028131623.zwuwguhm4v4s5imh@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, Oct 29, 2019 at 07:08:42AM +0000, Christopher Lameter wrote: > On Mon, 28 Oct 2019, Kirill A. Shutemov wrote: > > > Setting a single 4k page non-present in the direct mapping will require > > splitting 2M or 1G page we usually map direct mapping with. And it's one > > way road. We don't have any mechanism to map the memory with huge page > > again after the application has freed the page. > > > > It might be okay if all these pages cluster together, but I don't think we > > have a way to achieve it easily. > > Set aside a special physical memory range for this and migrate the > page to that physical memory range when MAP_EXCLUSIVE is specified? I've talked with Thomas yesterday and he suggested something similar: When the MAP_EXCLUSIVE request comes for the first time, we allocate a huge page for it and then use this page as a pool of 4K pages for subsequent requests. Once this huge page is full we allocate a new one and append it to the pool. When all the 4K pages that comprise the huge page are freed the huge page is collapsed. And then on top of this we can look into compaction of the direct map. Of course, this would work if the easy way of collapsing direct map pages Kirill mentioned on other mail will work. > Maybe some processors also have hardware ranges that offer additional > protection for stuff like that? > -- Sincerely yours, Mike.