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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D739EC7EE32 for ; Thu, 2 Mar 2023 15:14:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229765AbjCBPOZ (ORCPT ); Thu, 2 Mar 2023 10:14:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229607AbjCBPOS (ORCPT ); Thu, 2 Mar 2023 10:14:18 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A959D5274 for ; Thu, 2 Mar 2023 07:14:17 -0800 (PST) Received: from [192.168.10.12] (unknown [39.45.217.110]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: usama.anjum) by madras.collabora.co.uk (Postfix) with ESMTPSA id 8A60366018CA; Thu, 2 Mar 2023 15:14:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1677770056; bh=CcEqHND5mbOVDN70lUAK9blEjv5boHx15r9OKCOPiBw=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=hVqkMEDQ84QHoJNQe0kTCcPHsKDUFpk/1SRmYQtPjbYFeM94fajVPlOX8Fu6LNnv7 8hZR7OjZlrl5f7U86WL08LhzXM+aINLLCotPxs0eL+j2m6rbq853KKLCf9kZP08+y7 f9tG/h58lU7IcmNXyl9t84lK7PMdRJ8OwJlSANzkWvQ/c1MTz1+PnNvSnM5OjDQmSA 62vNnWRNHk+/5eDMMqTUKhrl4s9XenOqEyQA4p3DlUJ8f26jmte/KmZONQAwUpG1Bg 2LNyKZJSq0aMCYYPt4JRqORGUz8okXNFydnyI8PTuTx1OY56Flp2Y2ry5ncD9GI9FK a+VbBmjF1RXpg== Message-ID: Date: Thu, 2 Mar 2023 20:14:05 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli , Andrew Morton , Mike Rapoport , Axel Rasmussen , Nadav Amit , "kernel@collabora.com" Subject: Re: [PATCH v2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED To: David Hildenbrand , Peter Xu References: <20230227230044.1596744-1-peterx@redhat.com> <640319be-ddb6-d74f-b731-eee5ceab3d01@collabora.com> <8783f47e-76ea-cd24-e373-f2156884cd05@redhat.com> <982c1623-ac28-2743-d6a3-4faf42f72d47@redhat.com> Content-Language: en-US From: Muhammad Usama Anjum In-Reply-To: <982c1623-ac28-2743-d6a3-4faf42f72d47@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/2/23 7:01 PM, David Hildenbrand wrote: > On 02.03.23 14:57, Peter Xu wrote: >> On Thu, Mar 02, 2023 at 10:37:44AM +0100, David Hildenbrand wrote: >>> Especially for such large sparse VMAs, the current way of allocating >>> pagetables to place markers/zeropages is far from optimal. >> >> IMHO that's not a generic workload.  As mentioned in the reply there, I >> would suggest we go with simple then we have space to optimize it in the >> future if necessary, because the API will be the same. This is a good idea. I'm trying to understand why aren't we going with most optimized implementation. Why aren't we targeting it at this point in time? >> > > I disagree with "generic workload", we use sparse mmaps all over the place, > and when blindly used by e.g., CRIU, we'll simply end up wasting memory and > time. I've heard about a use case where a file of size 10s of GBs can be mapped to the memory and then accessed off and on. We need to handle this correctly and efficiently. > > But I already agreed that this optimization that is a separate thing to > implement. > -- BR, Muhammad Usama Anjum