From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932365AbbEWOdE (ORCPT ); Sat, 23 May 2015 10:33:04 -0400 Received: from verein.lst.de ([213.95.11.211]:37589 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753128AbbEWOdA (ORCPT ); Sat, 23 May 2015 10:33:00 -0400 Date: Sat, 23 May 2015 16:32:57 +0200 From: Christoph Hellwig To: Dan Williams Cc: linux-kernel@vger.kernel.org, Boaz Harrosh , Jan Kara , Mike Snitzer , Neil Brown , Benjamin Herrenschmidt , Dave Hansen , Heiko Carstens , Chris Mason , Paul Mackerras , "H. Peter Anvin" , j.glisse@gmail.com, mingo@kernel.org, Alasdair Kergon , linux-arch@vger.kernel.org, linux-nvdimm@ml01.01.org, hch@lst.de, mgorman@suse.de, Matthew Wilcox , Ross Zwisler , riel@redhat.com, david@fromorbit.com, Tejun Heo , axboe@kernel.dk, "Theodore Ts'o" , "Martin K. Petersen" , Julia Lawall , Martin Schwidefsky , linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org, Linus Torvalds Subject: Re: [PATCH v3 00/11] evacuate struct page from the block layer, introduce __pfn_t Message-ID: <20150523143257.GA19676@lst.de> References: <20150512042629.11521.70356.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150512042629.11521.70356.stgit@dwillia2-desk3.amr.corp.intel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I don't like this series at all, it does too much and too little at the same time. There's three totally different parts to it that are mixed up: (1) cleanups to use accessors for struct scatterlist instead of exposing the intricate details of chained S/G list to users (2) a switch of struct scatterlist to store a PFN instead of a page (3) switch struct bio_vec to store a struct PFN instead of a page (1) are pretty obvious cleanups, and they should have been submited separately long time ago. (2) seems like a good idea, but only when done properly, that is a full conversion to it. Not a you need a config option, in which case maybe some architectures and can sometimes deal with it if they driver says: meh, okay. Given that nature of SGLs most consumer want a physical address anyway, and it shouldn't be a problem to convert all others that need a kernel mapping to proper helpers. (3) I'm not sure about in it's current form. The bio_vec sees all kinds of highlevel use and we need to be a lot more careful about it, due to the way we e.g. use the in the iov_iter based read/write interfaces. It could be that pfn_t based approach there makes sense, but only if we ensure all consumer can always handle them. Because of that I'd suggest you try to get (1) and (2) done properly first, at that point we'll have how we can do (3) without causing a big mess.