Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [RFC PATCH 02/14] mm/hms: heterogenenous memory system (HMS) documentation | Date | Tue, 04 Dec 2018 09:06:59 -0800 |
| |
jglisse@redhat.com writes:
> + > +To help with forward compatibility each object as a version value and > +it is mandatory for user space to only use target or initiator with > +version supported by the user space. For instance if user space only > +knows about what version 1 means and sees a target with version 2 then > +the user space must ignore that target as if it does not exist.
So once v2 is introduced all applications that only support v1 break.
That seems very un-Linux and will break Linus' "do not break existing applications" rule.
The standard approach that if you add something incompatible is to add new field, but keep the old ones.
> +2) hbind() bind range of virtual address to heterogeneous memory > +================================================================ > + > +So instead of using a bitmap, hbind() take an array of uid and each uid > +is a unique memory target inside the new memory topology description.
You didn't define what an uid is?
user id?
Please use sensible terminology that doesn't conflict with existing usages.
I assume it's some kind of number that identifies a node in your graph.
> +User space also provide an array of modifiers. Modifier can be seen as > +the flags parameter of mbind() but here we use an array so that user > +space can not only supply a modifier but also value with it. This should > +allow the API to grow more features in the future. Kernel should return > +-EINVAL if it is provided with an unkown modifier and just ignore the > +call all together, forcing the user space to restrict itself to modifier > +supported by the kernel it is running on (i know i am dreaming about well > +behave user space).
It sounds like you're trying to define a system call with built in ioctl? Is that really a good idea?
If you need ioctl you know where to find it.
Please don't over design APIs like this.
> +3) Tracking and applying heterogeneous memory policies > +====================================================== > + > +Current memory policy infrastructure is node oriented, instead of > +changing that and risking breakage and regression HMS adds a new > +heterogeneous policy tracking infra-structure. The expectation is > +that existing application can keep using mbind() and all existing > +infrastructure under-disturb and unaffected, while new application > +will use the new API and should avoid mix and matching both (as they > +can achieve the same thing with the new API).
I think we need a stronger motivation to define a completely parallel and somewhat redundant infrastructure. What breakage are you worried about?
The obvious alternative would of course be to add some extra enumeration to the existing nodes.
It's a strange document. It goes from very high level to low level with nothing inbetween. I think you need a lot more details in the middle, in particularly how these new interfaces should be used. For example how should an application know how to look for a specific type of device? How is an automated tool supposed to use the enumeration? etc.
-Andi
| |