Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753394AbbD0QaZ (ORCPT ); Mon, 27 Apr 2015 12:30:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57752 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753255AbbD0QaV (ORCPT ); Mon, 27 Apr 2015 12:30:21 -0400 Message-ID: <553E6405.1060007@redhat.com> Date: Mon, 27 Apr 2015 12:29:57 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christoph Lameter , Jerome Glisse CC: "Paul E. McKenney" , Benjamin Herrenschmidt , linux-kernel@vger.kernel.org, linux-mm@kvack.org, jglisse@redhat.com, mgorman@suse.de, aarcange@redhat.com, airlied@redhat.com, aneesh.kumar@linux.vnet.ibm.com, Cameron Buschardt , Mark Hairgrove , Geoffrey Gerfin , John McKenna , akpm@linux-foundation.org Subject: Re: Interacting with coherent memory on external devices References: <20150424150829.GA3840@gmail.com> <20150424164325.GD3840@gmail.com> <20150424171957.GE3840@gmail.com> <20150424192859.GF3840@gmail.com> <20150425114633.GI5561@linux.vnet.ibm.com> <20150427154728.GA26980@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1193 Lines: 29 On 04/27/2015 12:17 PM, Christoph Lameter wrote: > On Mon, 27 Apr 2015, Jerome Glisse wrote: > >>> Improvements to the general code would be preferred instead of >>> having specialized solutions for a particular hardware alone. If the >>> general code can then handle the special coprocessor situation then we >>> avoid a lot of code development. >> >> I think Paul only big change would be the memory ZONE changes. Having a >> way to add the device memory as struct page while blocking the kernel >> allocation from using this memory. Beside that i think the autonuma changes >> he would need would really be specific to his usecase but would still >> reuse all of the low level logic. > > Well lets avoid that. Why would we want to avoid the sane approach that makes this thing work with the fewest required changes to core code? Just because your workload is different from the workload they are trying to enable? -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/