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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 4D586C12002 for ; Sat, 17 Jul 2021 02:58:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D9BF461278 for ; Sat, 17 Jul 2021 02:58:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9BF461278 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5A94A8D00F7; Fri, 16 Jul 2021 22:58:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57FDB8D00EC; Fri, 16 Jul 2021 22:58:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4215F8D00F7; Fri, 16 Jul 2021 22:58:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 1FF758D00EC for ; Fri, 16 Jul 2021 22:58:58 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D68C6231C7 for ; Sat, 17 Jul 2021 02:58:56 +0000 (UTC) X-FDA: 78370572672.07.1D4AC74 Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) by imf14.hostedemail.com (Postfix) with ESMTP id 9BE1760019B4 for ; Sat, 17 Jul 2021 02:58:56 +0000 (UTC) Received: by mail-io1-f51.google.com with SMTP id r18so1819969iot.4 for ; Fri, 16 Jul 2021 19:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=47x9Ymi/xIZW8qhaxWUdxGkotS2H57eORdaiodtNXxs=; b=AF1XCHuhA8nhTJo++znozASRZyrU/M9c/GDb1NcPrnBfe8JSqvJ1leXTvFT/vclguI tAQD9YTCbJ+Gf6knBaY2KForx1X1ESitUW8H76ZooVrOxpxEvwsDA1bQzwpSAYw9EyMu fZ2tKCEfQ8AXoaqz3qwFW3TGP/rMWVrI0PXdpsGjqomaItULuSUjPtcqZQyRRz+bjkBg cb4sbauRFzZa10tVHBmFZ9NP3lfEFFbSAQ0ZHEVU7nUImowKeMilk3iLekQGj1p/qN9f LjBQlP9larDZtlpbft1KBvl8PhW8+xhPs+VltNEYfMQ3PoIixbgH6gMu+WBi5HW9NTAY Bv9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=47x9Ymi/xIZW8qhaxWUdxGkotS2H57eORdaiodtNXxs=; b=Twzdmk/4XbkIwwjDHWmM8F3TSENt6ZJ/LsO5eENuz4pN/bPl0/3NlolBQkguThhKav zqdAEDg9aLJxdCMahCkmxK/N09e+1GVZPYT/oIV3TxGQA1Rbba/nuc/jSq6lVpT/W1UX bJtz5YHULpVFcLrLR/vVCWg3eWH60106C3+LLKO+CRemuuJIhpGg0eQzPwbrK1F1cRGJ eECafsaQjqXe3m5U2rKuRTh/dYMxMwbSB/NscXYKQeFmSi6WW4rs2W8YdhImiUwhXpUn Gcdti9rD4u4FmCXioHkMZRtlX/YVu6qOl/K6SjWDpZLEk4dys2OZMmrGrDpL+4rscxJR x7/Q== X-Gm-Message-State: AOAM530qQPTIfhhlaMaxW2dKNMgh6bbq5XqfMjYU6Yjx3MGT8DkjL/Qu HDv0ynCnxlBcGH7fhJC+uMA5R9Qs0HfgNLkFVjSSUw== X-Google-Smtp-Source: ABdhPJx+hHrUteqOCY+tNsE7hrkVQMh2XWLoapRd+165p+o9BiCxQOzq4l6FbCdFtFlaTD0a1Nwh2PUs6l/F/zMOx38= X-Received: by 2002:a05:6638:35a8:: with SMTP id v40mr12029573jal.126.1626490735538; Fri, 16 Jul 2021 19:58:55 -0700 (PDT) MIME-Version: 1.0 References: <20210619092002.1791322-1-pcc@google.com> <6c03ae36-9a4b-6646-66c3-04d4a3de9c1e@nvidia.com> In-Reply-To: From: Peter Collingbourne Date: Fri, 16 Jul 2021 19:58:44 -0700 Message-ID: Subject: Re: [PATCH v4] mm: introduce reference pages To: Matthew Wilcox Cc: John Hubbard , "Kirill A . Shutemov" , Andrew Morton , Catalin Marinas , Evgenii Stepanov , Jann Horn , Linux ARM , Linux Memory Management List , kernel test robot , Linux API , linux-doc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=AF1XCHuh; spf=pass (imf14.hostedemail.com: domain of pcc@google.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=pcc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Stat-Signature: w1weu6kupf9yx7h1d3njbpoxrkwwfu5t X-Rspamd-Queue-Id: 9BE1760019B4 X-HE-Tag: 1626490736-403014 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, Jun 28, 2021 at 12:57 PM Matthew Wilcox wrote: > > On Mon, Jun 28, 2021 at 12:44:22PM -0700, John Hubbard wrote: > > On 6/28/21 12:33 PM, Matthew Wilcox wrote: > > ... > > > > > > I wonder if single-byte captures enough of the useful possibilities. > > > In the kernel we have memset32() and memset64() [1] so we could support > > > a larger pattern than just an 8-bit byte. It all depends what userspace > > > would find useful. > > > > > > [1] Along with memset_p(), memset_l() and memset16() that aren't terribly > > > relevant to this use case. Although maybe memset_l() would be the right > > > one to use since there probably aren't too many 32-bit apps that want > > > a 64-bit pattern and memset64() might not be the fastest on a 32-bit > > > kernel). > > > > > > > And in fact, I'm also rather intrigued by doing something like 256 copies > > of a 16-byte UUID, per 4KB page. In other words, there are *definitely* > > useful patterns that are longer than a single byte, and it seems interesting > > to support them here. > > > > Kirill's idea of an API that somehow allows various power of 2 patterns seems > > like it would be nice, because then we don't have to pick a value that seems > > good in 2021, but less good as time goes by, perhaps. > > > > Another thought is to use an entire 4KB page as the smallest pattern unit. > > That would allow the maximum API flexibility, because the caller could > > explicitly set every single byte in the page. > > That's what this patch does. If it can be reduced to a pattern (in > Peter's patch of a single byte; i'm proposing expanding that), then > the page is filled with the pattern; otherwise we copy the reference > page. That sounds good. I propose that for now we only optimize the single byte pattern and single MTE granule use cases, and allow future expansion later via the size argument. Programs that use sizes with optimizations only implemented on newer kernels will still work on older kernels; they will just be faster on the new kernels. Peter