On Tue, Dec 04, 2018 at 09:13:33PM +0530, Aneesh Kumar K.V wrote: > Keith Busch <keith.busch@xxxxxxxxx> writes: > > > > Indeed, that particular example is out of scope for this series. The > > first objective is to aid a process running in node B's CPUs to allocate > > memory in B1. Anything that crosses QPI are their own. > > But if you can extrapolate how such a system can possibly be expressed > using what is propsed here, it would help in reviewing this. Expressed to what end? This proposal is not trying to express anything other than the best possible pairings because that is the most common information applications will want to know. > Also how > do we intent to express the locality of memory w.r.t to other computing > units like GPU/FPGA? The HMAT parsing at the end of the series provides an example for how others may use the proposed interfaces. > I understand that this is looked at as ACPI HMAT in sysfs format. > But as mentioned by others in this thread, if we don't do this platform > and device independent way, we can have application portability issues > going forward? Only the last patch is specific to HMAT. If there are other ways to get the same attributes, then those drivers or subsystems may also register them with these new kernel interfaces.
