On 10/26/2017 02:12 PM, Waiman Long wrote: > On 10/26/2017 10:39 AM, Tejun Heo wrote: >> Hello, Waiman. >> >> On Wed, Oct 25, 2017 at 11:50:34AM -0400, Waiman Long wrote: >>> Ping! Any comment on this patch? >> Sorry about the lack of response. Here are my two thoughts. >> >> 1. I'm not really sure about the memory part. Mostly because of the >> way it's configured and enforced is completely out of step with how >> mm behaves in general. I'd like to get more input from mm folks on >> this. > Yes, I also have doubt about which of the additional features are being > actively used. That is why the current patch exposes only the memory_migrate > flag in addition to the core *cpus and *mems control files. All the > other v1 features are not exposed waiting for further investigation and > feedback. One way to get more feedback is to have something that people > can play with. Maybe we could somehow tag it as experimental so that we > can change the interface later on, when necessary, if you have concern > about setting the APIs in stone. > >> 2. I want to think more about how we expose the effective settings. >> Not that anything is wrong with what cpuset does, but more that I >> wanna ensure that it's something we can follow in other cases where >> we have similar hierarchical property propagation. > Currently, the effective setting is exposed via the effective_cpus and > effective_mems control files. Unlike other controllers that control > resources, cpuset is unique in the sense that it is propagating > hierarchical constraints on CPUs and memory nodes down the tree. I > understand your desire to have a unified framework that can be applied > to most controllers, but I doubt cpuset is a good model in this regard. What do you think we can do for the 4.16 development cycle? I really like to see some kind of at least experimental support for cpuset v2. That may be the best way to gather feedback and decide what to do next. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
