Messages in this thread | | | From | "Huang, Ying" <> | Subject | Re: [RFC PATCH v3 0/4] Node Weights and Weighted Interleave | Date | Mon, 06 Nov 2023 13:08:59 +0800 |
| |
Michal Hocko <mhocko@suse.com> writes:
> On Fri 03-11-23 15:10:37, Huang, Ying wrote: >> Michal Hocko <mhocko@suse.com> writes: >> >> > On Thu 02-11-23 14:11:09, Huang, Ying wrote: >> >> Michal Hocko <mhocko@suse.com> writes: >> >> >> >> > On Wed 01-11-23 10:21:47, Huang, Ying wrote: >> >> >> Michal Hocko <mhocko@suse.com> writes: >> >> > [...] >> >> >> > Well, I am not convinced about that TBH. Sure it is probably a good fit >> >> >> > for this specific CXL usecase but it just doesn't fit into many others I >> >> >> > can think of - e.g. proportional use of those tiers based on the >> >> >> > workload - you get what you pay for. >> >> >> >> >> >> For "pay", per my understanding, we need some cgroup based >> >> >> per-memory-tier (or per-node) usage limit. The following patchset is >> >> >> the first step for that. >> >> >> >> >> >> https://lore.kernel.org/linux-mm/cover.1655242024.git.tim.c.chen@linux.intel.com/ >> >> > >> >> > Why do we need a sysfs interface if there are plans for cgroup API? >> >> >> >> They are for different target. The cgroup API proposed here is to >> >> constrain the DRAM usage in a system with DRAM and CXL memory. The less >> >> you pay, the less DRAM and more CXL memory you use. >> > >> > Right, but why the usage distribution requires its own interface and >> > cannot be combined with the access control part of it? >> >> Per my understanding, they are orthogonal. >> >> Weighted-interleave is a memory allocation policy, other memory >> allocation policies include local first, etc. >> >> Usage limit is to constrain the usage of specific memory types >> (e.g. DRAM) for a cgroup. It can be used together with local first >> policy and some other memory allocation policy. > > Bad wording from me. Sorry for the confusion.
Never mind.
> Sure those are two orthogonal things and I didn't mean to suggest a > single API to cover both. But if cgroup semantic can be reasonably > defined for the usage enforcement can we put the interleaving behavior > API under the same cgroup controller as well?
I haven't thought about it thoroughly. But I think it should be the direction.
-- Best Regards, Huang, Ying
| |