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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 7F435C11F64 for ; Mon, 28 Jun 2021 19:58:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 18DDE61CB4 for ; Mon, 28 Jun 2021 19:58:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18DDE61CB4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 54DC98D006E; Mon, 28 Jun 2021 15:58:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D6D98D0016; Mon, 28 Jun 2021 15:58:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3503A8D006E; Mon, 28 Jun 2021 15:58:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0219.hostedemail.com [216.40.44.219]) by kanga.kvack.org (Postfix) with ESMTP id 08B6F8D0016 for ; Mon, 28 Jun 2021 15:58:13 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E7ABB180BD9B6 for ; Mon, 28 Jun 2021 19:58:13 +0000 (UTC) X-FDA: 78304194066.01.ABA5077 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 226A6548 for ; Mon, 28 Jun 2021 19:58:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=5mZU8eaHkGitYCk/uZMPD+d5aeydTQi9vAR1U5mhi2k=; b=JrcRDsZNk4S8DYa8U89O3uL3ow Q88duty2KLVv6mkMEFl9D1zPR80VMuiQ76pZ8TP+slMia26pg35s4DQfpEfCfncCEYRp0x4maO2R5 KPrkT75um9OgbJVCseuy3veg4wpnacFOfBKuZhL3rjEIP05lsywUgFRxAqED+2PXTYsodmdsa/RMw jWAOT+W+bC8t5eyHO0QAKKf5y5jAcmNK0lJSSu1g6lAlf+RGUTi2dQaBH3iQmEmlApFlK86s3jrww XCv5HEvse8L1tw8UiCoUrJpeknbwVD6sJ0qnkyIRG9U7feuuY/duFoijNSNWZH+ThmBTSPaowFqGs 5BgVeHbQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1lxxMh-003OEh-S6; Mon, 28 Jun 2021 19:56:50 +0000 Date: Mon, 28 Jun 2021 20:56:19 +0100 From: Matthew Wilcox To: John Hubbard Cc: Peter Collingbourne , "Kirill A . Shutemov" , Andrew Morton , Catalin Marinas , Evgenii Stepanov , Jann Horn , Linux ARM , linux-mm@kvack.org, kernel test robot , Linux API , linux-doc@vger.kernel.org Subject: Re: [PATCH v4] mm: introduce reference pages Message-ID: References: <20210619092002.1791322-1-pcc@google.com> <6c03ae36-9a4b-6646-66c3-04d4a3de9c1e@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c03ae36-9a4b-6646-66c3-04d4a3de9c1e@nvidia.com> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 226A6548 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JrcRDsZN; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Stat-Signature: j5iamx3dw7osejm8ihhzwjtwwqycs4ii X-HE-Tag: 1624910293-113338 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: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.