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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD312C433F5 for ; Thu, 21 Oct 2021 12:35:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D68661205 for ; Thu, 21 Oct 2021 12:35:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5D68661205 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 0B90494000D; Thu, 21 Oct 2021 08:35:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 04180900002; Thu, 21 Oct 2021 08:35:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4CBC94000D; Thu, 21 Oct 2021 08:35:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id D51D6900002 for ; Thu, 21 Oct 2021 08:35:41 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7E0B81803A181 for ; Thu, 21 Oct 2021 12:35:41 +0000 (UTC) X-FDA: 78720390882.10.0E6059B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf15.hostedemail.com (Postfix) with ESMTP id C877DD00009D for ; Thu, 21 Oct 2021 12:35:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634819740; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pcCL6CdZH83Z0UE+ms2Bf+J5zETTW6d5Cs7+RZXJ0w4=; b=EPSBrSrhKTRw9DvEFSuhkjW2WofMAFjcKDG4dxuMfIYJR+WTmNODvSLu4yGPGbWRlpSo7R 6at/C3Pcyjv5WlfaDq4jbth8mrJRaLlFnLXx/qRqs7PSa/xODSUskfL44CEUuTQoHQbLxn xOPRC45IJv+26BZz60QGwb7M466+I20= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-457-dfC0OmO7N9e7-TSFv8uVkw-1; Thu, 21 Oct 2021 08:35:35 -0400 X-MC-Unique: dfC0OmO7N9e7-TSFv8uVkw-1 Received: by mail-wm1-f72.google.com with SMTP id g4-20020a1c9d04000000b0030dd4dd6659so1697427wme.3 for ; Thu, 21 Oct 2021 05:35:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=pcCL6CdZH83Z0UE+ms2Bf+J5zETTW6d5Cs7+RZXJ0w4=; b=LfjLZaZs6nNCM34lWkqH0GYcwuqFSOXTgVDEQEFCa8g3YvHiDU0i/YYIOLp39bVMTs sHkKnwNyupkorcRzRRHIfcT6HBYmKqDUyBb9kDMCeKj+47DR9FhlL9y+5iB7/QJ4o/tn cKOVHIBajEn7E+9jMvRMf1TjcwmlkfLMRa1F5kSkLpbYV9aDlWFO2NDgB11Ne5mr4HBk 1hB+kZZwwdZz72Ym+ZmZZQOtmW81o8HZAWMPGfRCh6I+yU+DXZFlMKVN2pKd/wCm8Tst 1m7nP55uRyaJW9NMT8BOZOaOFBhIRMhPkMkLaza4hZQkr3cxvsDgeoF/5bvISs5tKZEz eoLw== X-Gm-Message-State: AOAM530JZKIoXwml+G0nPoeT5SAq0B4ZJaQPc5iSiX7iRNrHrgZTKJQ3 gSc69Y1X/d+/uZxhpkJx4Oc3Tbx52xO7nphy/pJd2kLmTCe62NsxWsezntCQ9uAnpo2VP55Uw0v WEi8HXRG54O8= X-Received: by 2002:a5d:598a:: with SMTP id n10mr6855148wri.93.1634819734172; Thu, 21 Oct 2021 05:35:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygTB13YIzbisqOQrzKIUBIvuJx4J8sCISPd+GfQ3nZfE1HhayO8oEr5WMTr4X9Cpc4e9kMVQ== X-Received: by 2002:a5d:598a:: with SMTP id n10mr6855104wri.93.1634819733890; Thu, 21 Oct 2021 05:35:33 -0700 (PDT) Received: from [192.168.3.132] (p4ff23aba.dip0.t-ipconnect.de. [79.242.58.186]) by smtp.gmail.com with ESMTPSA id x7sm4732213wrq.69.2021.10.21.05.35.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Oct 2021 05:35:33 -0700 (PDT) Message-ID: <2fc2c5da-c0e9-b954-ba48-e258b88e3271@redhat.com> Date: Thu, 21 Oct 2021 14:35:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 To: Kent Overstreet Cc: Christoph Hellwig , Matthew Wilcox , Johannes Weiner , "Kirill A. Shutemov" , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , David Howells , Hugh Dickins References: <20211018231627.kqrnalsi74bgpoxu@box.shutemov.name> <996b3ac4-1536-2152-f947-aad6074b046a@redhat.com> <436a9f9c-d5af-7d12-b7d2-568e45ffe0a0@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: Folios for 5.15 request - Was: re: Folio discussion recap - In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C877DD00009D Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=EPSBrSrh; spf=none (imf15.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: ijrqk6ecqi1u5bxupynk6c4i6pu3udma X-Rspamd-Server: rspam06 X-HE-Tag: 1634819736-525551 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 21.10.21 14:03, Kent Overstreet wrote: > On Thu, Oct 21, 2021 at 09:21:17AM +0200, David Hildenbrand wrote: >> On 21.10.21 08:51, Christoph Hellwig wrote: >>> FYI, with my block and direct I/O developer hat on I really, really >>> want to have the folio for both file and anon pages. Because to make >>> the get_user_pages path a _lot_ more efficient it should store folios. >>> And to make that work I need them to work for file and anon pages >>> because for get_user_pages and related code they are treated exactly >>> the same. > > ++ > >> Thanks, I can understand that. And IMHO that would be even possible with >> split types; the function prototype will simply have to look a little >> more fancy instead of replacing "struct page" by "struct folio". :) > > Possible yes, but might it be a little premature to split them? Personally, I think it's the right thing to do to introduce something limited like "struct filemap" (again, bad name, i.e., folio restricted to the filemap API) first and avoid introducing a generic folio thingy. So I'd even consider going with folios all the way premature. But I assume what to consider premature and what not depends on the point of view already. And maybe that's the biggest point where we all disagree. Anyhow, what I don't quite understand is the following: as the first important goal, we want to improve the filemap API; that's a noble goal and I highly appreciate Willy's work. To improve the API, there is absolutely no need introduce generic folio. Yet we argue about whether generic folio vs. filemap specific folio seems to be the right thing to do as a first step. My opinion after all the discussions: use a dedicate type with a clear name to solve the immediate filemap API issue. Leave the remainder alone for now. Less code to touch, less subsystems to involve (well, still a lot), less people to upset, less discussions to have, faster review, faster upstream, faster progress. A small but reasonable step. But maybe I'm just living in a dream world :) -- Thanks, David / dhildenb