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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 676D2C04EB8 for ; Tue, 4 Dec 2018 20:30:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EA12B2082B for ; Tue, 4 Dec 2018 20:30:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA12B2082B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=deltatee.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726354AbeLDUaV (ORCPT ); Tue, 4 Dec 2018 15:30:21 -0500 Received: from ale.deltatee.com ([207.54.116.67]:54130 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726056AbeLDUaV (ORCPT ); Tue, 4 Dec 2018 15:30:21 -0500 Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtp (Exim 4.89) (envelope-from ) id 1gUHKX-00006B-5x; Tue, 04 Dec 2018 13:30:05 -0700 To: Jerome Glisse Cc: Dan Williams , Andi Kleen , Linux MM , Andrew Morton , Linux Kernel Mailing List , "Rafael J. Wysocki" , Ross Zwisler , Dave Hansen , Haggai Eran , balbirs@au1.ibm.com, "Aneesh Kumar K.V" , Benjamin Herrenschmidt , "Kuehling, Felix" , Philip.Yang@amd.com, "Koenig, Christian" , "Blinzer, Paul" , John Hubbard , rcampbell@nvidia.com References: <20181203233509.20671-1-jglisse@redhat.com> <20181203233509.20671-3-jglisse@redhat.com> <875zw98bm4.fsf@linux.intel.com> <20181204182421.GC2937@redhat.com> <20181204185725.GE2937@redhat.com> <20181204192221.GG2937@redhat.com> <20181204201347.GK2937@redhat.com> From: Logan Gunthorpe Message-ID: <2f146730-1bf9-db75-911d-67809fc7afef@deltatee.com> Date: Tue, 4 Dec 2018 13:30:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181204201347.GK2937@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: rcampbell@nvidia.com, jhubbard@nvidia.com, Paul.Blinzer@amd.com, christian.koenig@amd.com, Philip.Yang@amd.com, felix.kuehling@amd.com, benh@kernel.crashing.org, aneesh.kumar@linux.ibm.com, balbirs@au1.ibm.com, haggaie@mellanox.com, dave.hansen@intel.com, ross.zwisler@linux.intel.com, rafael@kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, ak@linux.intel.com, dan.j.williams@intel.com, jglisse@redhat.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [RFC PATCH 02/14] mm/hms: heterogenenous memory system (HMS) documentation X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-12-04 1:13 p.m., Jerome Glisse wrote: > You are right many are non exclusive. It is just my feeling that having > a mask as a file inside the target directory might be overlook by the > application which might start using things it should not. At same time > i guess if i write the userspace library that abstract this kernel API > then i can enforce application to properly select thing. I think this is just evidence that this is not a good API. If the user has the option to just ignore things or do it wrong that's a problem with the API. Using a prefix for the name doesn't change that fact. > I do not think there is a way to answer that question. I am siding on the > side of this API can be dumb down in userspace by a common library. So let > expose the topology and let userspace dumb it down. I fundamentally disagree with this approach to designing APIs. Saying "we'll give you the kitchen sink, add another layer to deal with the complexity" is actually just eschewing API design and makes it harder for kernel folks to know what userspace actually requires because they are multiple layers away. > If we dumb it down in the kernel i see few pitfalls: > - kernel dumbing it down badly > - kernel dumbing down code can grow out of control with gotcha > for platform This is just a matter of designing the APIs well. Don't do it badly. > - it is still harder to fix kernel than userspace in commercial > user space (the whole RHEL business of slow moving and long > supported kernel). So on those being able to fix thing in > userspace sounds pretty enticing I hear this argument a lot and it's not compelling to me. I don't think we should make decisions in upstream code to allow RHEL to bypass the kernel simply because it would be easier for them to distribute code changes. Logan