> > > Bonus Configuration: HBM device memory tiering > > > ============================================== > > > echo 1 > dax0.0/private # make the node private > > > echo 0 > dax0.0/adistance # highest tier > > > echo 1 > dax0.0/reclaim # reclaim active > > > echo 1 > dax0.0/demotion # may demote from the node > > > echo 1 > dax0.0/user_numa # mbind() > > > echo online_movable > dax0.0/state > > > echo 1 > numa/demotion_enabled > > > > I am bit confused by the HBM device example being discovered as a DAX > > device. Is it to > > only to showcase the use-case? Or we see HBM device is actually > > expected to be discovered as > > DAX device with N_MEMORY_PRIVATE? > > > > "actually expected to be" -> no. there's no requirement HBM be > discovered and boudn to DAX, DAX is simply a convenient intermediary > to memory-hotplug. This is at best a demonstration. > > A device driver could very well just call memory-hotplug directly, > or its memory could be brought up as a private node via a boot > paremeter (which I have sculpted for v7). The former is preferred, > but there's a bit of a chicken/egg scenario for bootstrapping.
I find this interesting as this appears to be evolving towards a vendor agnostic framework for hotplugging memory directly to private nodes. How you see this working? In particular, How would the kernel know which memory ranges correspond to HBM or other device memory? Please also CC me when you post v7: [email protected] Thanks, Pankaj > > Most of these UAPI extensions are going to be consolidated into a > debugfs interface for testing purposes only in v7. I've been working > on aggressive Linux Test Project test expansion to ensure there is no > UAPI regressions. > > ~Gregory
