From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by kanga.kvack.org (Postfix) with ESMTP id E46AA6B7D0D for ; Thu, 6 Dec 2018 18:29:35 -0500 (EST) Received: by mail-io1-f69.google.com with SMTP id k4so1898128ioc.10 for ; Thu, 06 Dec 2018 15:29:35 -0800 (PST) Received: from ale.deltatee.com (ale.deltatee.com. [207.54.116.67]) by mx.google.com with ESMTPS id u4si1062199itj.4.2018.12.06.15.29.34 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 06 Dec 2018 15:29:34 -0800 (PST) References: <20181205001544.GR2937@redhat.com> <42006749-7912-1e97-8ccd-945e82cebdde@intel.com> <20181205021334.GB3045@redhat.com> <20181205175357.GG3536@redhat.com> <20181206192050.GC3544@redhat.com> <20181206223935.GG3544@redhat.com> From: Logan Gunthorpe Message-ID: <935fc14d-91f2-bc2a-f8b5-665e4145e148@deltatee.com> Date: Thu, 6 Dec 2018 16:28:44 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit Subject: Re: [RFC PATCH 00/14] Heterogeneous Memory System (HMS) and hbind() Sender: owner-linux-mm@kvack.org List-ID: To: Dave Hansen , Jerome Glisse Cc: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, "Rafael J . Wysocki" , Matthew Wilcox , Ross Zwisler , Keith Busch , Dan Williams , Haggai Eran , Balbir Singh , "Aneesh Kumar K . V" , Benjamin Herrenschmidt , Felix Kuehling , Philip Yang , =?UTF-8?Q?Christian_K=c3=b6nig?= , Paul Blinzer , John Hubbard , Ralph Campbell , Michal Hocko , Jonathan Cameron , Mark Hairgrove , Vivek Kini , Mel Gorman , Dave Airlie , Ben Skeggs , Andrea Arcangeli , Rik van Riel , Ben Woodard , linux-acpi@vger.kernel.org On 2018-12-06 4:09 p.m., Dave Hansen wrote: > This looks great. But, we don't _have_ this kind of information for any > system that I know about or any system available in the near future. > > We basically have two different world views: > 1. The system is described point-to-point. A connects to B @ > 100GB/s. B connects to C at 50GB/s. Thus, C->A should be > 50GB/s. > * Less information to convey > * Potentially less precise if the properties are not perfectly > additive. If A->B=10ns and B->C=20ns, A->C might be >30ns. > * Costs must be calculated instead of being explicitly specified > 2. The system is described endpoint-to-endpoint. A->B @ 100GB/s > B->C @ 50GB/s, A->C @ 50GB/s. > * A *lot* more information to convey O(N^2)? > * Potentially more precise. > * Costs are explicitly specified, not calculated > > These patches are really tied to world view #1. But, the HMAT is really > tied to world view #1. I didn't think this was meant to describe actual real world performance between all of the links. If that's the case all of this seems like a pipe dream to me. Attributes like cache coherency, atomics, etc should fit well in world view #1... and, at best, some kind of flag saying whether or not to use a particular link if you care about transfer speed. -- But we don't need special "link" directories to describe the properties of existing buses. You're not *really* going to know bandwidth or latency for any of this unless you actually measure it on the system in question. Logan