From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by kanga.kvack.org (Postfix) with ESMTP id 3291A6B0006 for ; Thu, 4 Oct 2018 15:46:47 -0400 (EDT) Received: by mail-qk1-f200.google.com with SMTP id p73-v6so9802994qkp.2 for ; Thu, 04 Oct 2018 12:46:47 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id s3-v6sor3875272qvb.68.2018.10.04.12.46.46 for (Google Transport Security); Thu, 04 Oct 2018 12:46:46 -0700 (PDT) MIME-Version: 1.0 References: <20181003185854.GA1174@jordon-HP-15-Notebook-PC> <20181003200003.GA9965@bombadil.infradead.org> <20181003221444.GZ30658@n2100.armlinux.org.uk> <20181004123400.GC30658@n2100.armlinux.org.uk> <20181004181736.GB20842@bombadil.infradead.org> In-Reply-To: From: Miguel Ojeda Date: Thu, 4 Oct 2018 21:46:34 +0200 Message-ID: Subject: Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Souptick Joarder Cc: Matthew Wilcox , linux@armlinux.org.uk, Robin van der Gracht , stefanr@s5r6.in-berlin.de, hjc@rock-chips.com, =?UTF-8?Q?Heiko_St=C3=BCbner?= , Dave Airlie , robin.murphy@arm.com, iamjoonsoo.kim@lge.com, Andrew Morton , Marek Szyprowski , Kees Cook , treding@nvidia.com, mhocko@suse.com, Dan Williams , kirill.shutemov@linux.intel.com, Mark Rutland , Andrey Ryabinin , Dmitry Vyukov , Kate Stewart , tchibo@google.com, riel@redhat.com, minchan@kernel.org, Peter Zijlstra , ying.huang@intel.com, Andi Kleen , rppt@linux.vnet.ibm.com, Dominik Brodowski , Arnd Bergmann , cpandya@codeaurora.org, hannes@cmpxchg.org, Joe Perches , mcgrof@kernel.org, Linux ARM , linux-kernel , linux1394-devel@lists.sourceforge.net, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, Linux-MM Hi Souptick, On Thu, Oct 4, 2018 at 8:49 PM Souptick Joarder wrote: > > On Thu, Oct 4, 2018 at 11:47 PM Matthew Wilcox wrote: > > > > I think this is a bad plan. What we should rather do is examine the current > > users of vm_insert_page() and ask "What interface would better replace > > vm_insert_page()?" > > > > As I've said to you before, I believe the right answer is to have a > > vm_insert_range() which takes an array of struct page pointers. That > > fits the majority of remaining users. > > Ok, but it will take some time. > Is it a good idea to introduce the final vm_fault_t patch and then > start working on vm_insert_range as it will be bit time consuming ? > Well, why is there a rush? Development should be done in a patch series or a tree, and submitted as a whole, instead of sending partial patches. Also, not sure if you saw my comments/review: if the interface is not going to change, why the name change? Why can't we simply keep using vm_insert_page? Cheers, Miguel