Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1054050pxb; Tue, 9 Feb 2021 21:36:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJwqZY06dxhjeE4NbY60rzXqT+93b7fTuC38OhGJ/rPA5dcu/AUJLsDkG1THo7S3J/O9yi1N X-Received: by 2002:aa7:d696:: with SMTP id d22mr1493443edr.361.1612935387210; Tue, 09 Feb 2021 21:36:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612935387; cv=none; d=google.com; s=arc-20160816; b=S3RGGC73J3zdV0v8PfBo6O405eoNTD1fCT8x61bTexblmynnzPO6cE7bSoOYAklzY+ fOEAOzJMI1bYJ7mtYYTYulx8l1zThq7o55/CTN9faSvEuStcJ5H84REwtUFDVVDRNPLQ SwREvwtTgQ72XMS0OnqkvYjc8OzwXDu8wSLeQDAYdJWKB0tvnTOGGhzjdLsI6c0F6QHZ CXPDzJZmJz9NfGLgggU2WZCSdEVI5aj1KKCi565EoqMLR0i8aUddLjmz5ZZkuy3pxQTx vYYssiS0Q6zLOPvnOEIzwwgAtULAy4w+Kabdv32BmyxS6NtVg5RkWrQQNe+T6usbXlz5 fpZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date; bh=ngZibdd6LaHYhLVxni9FX81o3W20BRdQ/qoxTK3qyVI=; b=c//VbtLZ8VBdmQf3SCZYwY5Sill+kDdEsM71Fv5LXCXjIk9K/3uDn78B6JEZ1b0/QE MjkQl8buYCDQUo/LOrjlt4x6mVs6qsbD7juIJVOj2ezt1eW51ATmeTQGMmhT/mhELoRB zBeXrCc/UO0hTYMNHZorZVA45wDeGeTxYP7DSwe2JWg/qUMClMoH1sHgCqI3L/G7T8Ux 0j4PzbRT/FeDiDFkPx1oMtzKr8Z9xUy8EvpSB9a4jQqKHBLpmR61+I9SnmDJ5fLYZJc1 tR+GiZvFFBpul7v+E7tEusjWW9aQlvSmV667N1ABfaZ8dmsXSTlQP0EE3Cjsin3d8QKh vKZw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y13si732573edd.436.2021.02.09.21.36.03; Tue, 09 Feb 2021 21:36:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232405AbhBIPOD (ORCPT + 99 others); Tue, 9 Feb 2021 10:14:03 -0500 Received: from mx2.suse.de ([195.135.220.15]:41388 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231915AbhBIPN6 (ORCPT ); Tue, 9 Feb 2021 10:13:58 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C7473B207; Tue, 9 Feb 2021 15:13:16 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 94CEDDA7C8; Tue, 9 Feb 2021 16:11:23 +0100 (CET) Date: Tue, 9 Feb 2021 16:11:23 +0100 From: David Sterba To: ira.weiny@intel.com Cc: Andrew Morton , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 0/4] btrfs: Convert kmaps to core page calls Message-ID: <20210209151123.GT1993@suse.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, ira.weiny@intel.com, Andrew Morton , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <20210205232304.1670522-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210205232304.1670522-1-ira.weiny@intel.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 05, 2021 at 03:23:00PM -0800, ira.weiny@intel.com wrote: > From: Ira Weiny > > There are many places where kmap//kunmap patterns occur. We lift > these various patterns to core common functions and use them in the btrfs file > system. At the same time we convert those core functions to use > kmap_local_page() which is more efficient in those calls. > > I think this is best accepted through Andrew's tree as it has the mem*_page > functions in it. But I'd like to get an ack from David or one of the other > btrfs maintainers before the btrfs patches go through. I'd rather take the non-mm patches through my tree so it gets tested the same way as other btrfs changes, straightforward cleanups or not. This brings the question how to do that as the first patch should go through the MM tree. One option is to posptpone the actual cleanups after the 1st patch is merged but this could take a long delay. I'd suggest to take the 1st patch within MM tree in the upcoming merge window and then I can prepare a separate pull with just the cleanups. Removing an inter-tree patch dependency was a sufficient reason for Linus in the past for such pull requests. > There are a lot more kmap->kmap_local_page() conversions but kmap_local_page() > requires some care with the unmapping order and so I'm still reviewing those > changes because btrfs uses a lot of loops for it's kmaps. It sounds to me that converting the kmaps will take some time anyway so exporting the helpers first and then converting the subsystems might be a good option. In case you'd like to get rid of the simple cases in btrfs code now we can do the 2 pull requests.