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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 23650C433E0 for ; Wed, 3 Feb 2021 14:00:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 26C6764E4B for ; Wed, 3 Feb 2021 14:00:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 26C6764E4B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 520D56B0005; Wed, 3 Feb 2021 09:00:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D21E6B006E; Wed, 3 Feb 2021 09:00:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C0746B0070; Wed, 3 Feb 2021 09:00:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 2400C6B0005 for ; Wed, 3 Feb 2021 09:00:19 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A91153637 for ; Wed, 3 Feb 2021 14:00:18 +0000 (UTC) X-FDA: 77777116116.01.dog19_5e05398275d4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 8206A10046464 for ; Wed, 3 Feb 2021 14:00:18 +0000 (UTC) X-HE-Tag: dog19_5e05398275d4 X-Filterd-Recvd-Size: 5131 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Wed, 3 Feb 2021 14:00:17 +0000 (UTC) Received: by mail-qt1-f174.google.com with SMTP id z32so150120qtd.8 for ; Wed, 03 Feb 2021 06:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wJ+9yGGyku726Fmhx6VA5s47tWt2QRSJZr3QMNhgXi8=; b=LE7U/OxlvMOLCeJKV5W2LOjo71WvODo9PJaGIz1NiWr9sWessOu+ZKfLM74lMAmEHu e8gX2TWWeo3/Da2sCByEOpaWnFErP4MIJlli951RdrrmSkDKcZQZIlf7mW9lxyoXb4l8 dYA+0mmu9449XB6qvuYasR/eRyZxUfoy5rL9IzDj9wojRTmaQ9QU9m4K7zhvuJe51+L2 qo8ivy9KrEEX0smtzCT6teS/W4pPmP6MlN3rgoZ1XmA+Pk58e5gEufK4JQi3CFbVIpTr dVMQJPypWuh2q7jaQt4sw+so6f6mtW9F379aVUYmYmiBvilL/zVt0SJL4QFKSCYApOYz VSKA== 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; bh=wJ+9yGGyku726Fmhx6VA5s47tWt2QRSJZr3QMNhgXi8=; b=lRBSdzOTN+hCP9mCGeiJZDPjYHuWTqWbKBxQP41rY+BGxB50gXcxKotSKtoQS6SWeR CombxDdKTZUfj+lbG8x+gFO81oVIlKYLV6eoC96rfA1yBs/+8scgPCHROHJD17AOkGL0 OhNv99+J5GQcUx7eghhNrFKT1N/86SidgxCgTumBKYX7jqbZ46HQot1cZph+10VeMLxL on0HKITjfWZQkQnCGQuaDrE7ramUHQqHxKCkyrhLMQxJkVjDU9aLGy8YZt3RuBQq05st /hobawC2Y1lcddC5Iof9qI+RPqcPqBlqvnSDD058t6LV+pUsTCz+IVRnxG6BJ4eHXyfW yv0g== X-Gm-Message-State: AOAM531vd6nL7jJsB0lQoRV1ubT8zcNAwUXJHJDOCIBmpvBZEJnjnrHs z5+fCJqaiQoneN7o/GvkfjgG/Q== X-Google-Smtp-Source: ABdhPJysYd6gW3Yn+bme0w5Tc++3D1cbKiW0SwSo45oVCtlU9ebsBZcNFwOLg1YSFToUDcm3XDAggg== X-Received: by 2002:ac8:5a48:: with SMTP id o8mr2501828qta.196.1612360817039; Wed, 03 Feb 2021 06:00:17 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-115-133.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.115.133]) by smtp.gmail.com with ESMTPSA id o17sm611051qtl.47.2021.02.03.06.00.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Feb 2021 06:00:16 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1l7Ihb-0030iv-BO; Wed, 03 Feb 2021 10:00:15 -0400 Date: Wed, 3 Feb 2021 10:00:15 -0400 From: Jason Gunthorpe To: Gal Pressman Cc: aarcange@redhat.com, akpm@linux-foundation.org, gokhale2@llnl.gov, hch@lst.de, jack@suse.cz, jannh@google.com, jhubbard@nvidia.com, kirill@shutemov.name, ktkhai@virtuozzo.com, leonro@nvidia.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mcfadden8@llnl.gov, oleg@redhat.com, peterx@redhat.com, torvalds@linux-foundation.org, wzam@amazon.com, yang.shi@linux.alibaba.com Subject: Re: [PATCH 1/4] mm: Trial do_wp_page() simplification Message-ID: <20210203140015.GP4718@ziepe.ca> References: <20210202171327.GN4718@ziepe.ca> <20210203124358.59017-1-galpress@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210203124358.59017-1-galpress@amazon.com> 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 Wed, Feb 03, 2021 at 02:43:58PM +0200, Gal Pressman wrote: > > On Tue, Feb 02, 2021 at 12:05:36PM -0500, Peter Xu wrote: > > > >> > Gal, you could also MADV_DONTFORK this range if you are explicitly > >> > allocating them via special mmap. > >> > >> Yeah I wanted to mention this one too but I just forgot when reply: the issue > >> thread previously pasted smells like some people would like to drop > >> MADV_DONTFORK, but if it's able to still be applied I don't know why > >> not.. > > > > I want to drop the MADV_DONTFORK for dynamic data memory allocated by > > the application layers (eg with malloc) without knowledge of how they > > will be used. > > > > This case is a buffer internal to the communication system that we > > know at allocation time how it will be used; so an explicit, > > deliberate, MADV_DONTFORK is fine > > We are referring to libfabric's bounce buffers, correct? > Libfabric could be considered as the "app" here, it's not clear why these > buffers should be DONTFORK'd before ibv_reg_mr() but others don't. I assumed they were internal to the EFA code itself. > Anyway, it should be simple enough to madvise them after allocation, although I > think it's part of libfabric's generic code (which isn't necessarily used on > top of rdma-core). Ah, so that is a reasonable justification for wanting to fix this in the kernel.. Lets give Peter some time first. The other direction to validate this approach is to remove the MAP_HUGETLB flags and rely on THP instead, and/or mark them as MAP_SHARED. I'm not sure generic code should be use using MAP_HUGETLB.. This would be enough to confirm that everything else is working as expected Thanks, Jason