lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 02 Jul 2020 13:02:03 +0800 From: "Huang\, Ying" <ying.huang@...el.com> To: David Rientjes <rientjes@...gle.com> Cc: Dave Hansen <dave.hansen@...el.com>, Dave Hansen <dave.hansen@...ux.intel.com>, <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>, <kbusch@...nel.org>, <yang.shi@...ux.alibaba.com>, <dan.j.williams@...el.com> Subject: Re: [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of discard David Rientjes <rientjes@...gle.com> writes: > On Wed, 1 Jul 2020, Dave Hansen wrote: > >> > Could this cause us to break a user's mbind() or allow a user to >> > circumvent their cpuset.mems? >> >> In its current form, yes. >> >> My current rationale for this is that while it's not as deferential as >> it can be to the user/kernel ABI contract, it's good *overall* behavior. >> The auto-migration only kicks in when the data is about to go away. So >> while the user's data might be slower than they like, it is *WAY* faster >> than they deserve because it should be off on the disk. >> > > It's outside the scope of this patchset, but eventually there will be a > promotion path that I think requires a strict 1:1 relationship between > DRAM and PMEM nodes because otherwise mbind(), set_mempolicy(), and > cpuset.mems become ineffective for nodes facing memory pressure. I have posted an patchset for AutoNUMA based promotion support, https://lore.kernel.org/lkml/20200218082634.1596727-1-ying.huang@intel.com/ Where, the page is promoted upon NUMA hint page fault. So all memory policy (mbind(), set_mempolicy(), and cpuset.mems) are available. We can refuse promoting the page to the DRAM nodes that are not allowed by any memory policy. So, 1:1 relationship isn't necessary for promotion. > For the purposes of this patchset, agreed that DRAM -> PMEM -> swap makes > perfect sense. Theoretically, I think you could have DRAM N0 and N1 and > then a single PMEM N2 and this N2 can be the terminal node for both N0 and > N1. On promotion, I think we need to rely on something stronger than > autonuma to decide which DRAM node to promote to: specifically any user > policy put into effect (memory tiering or autonuma shouldn't be allowed to > subvert these user policies). > > As others have mentioned, we lose the allocation or process context at the > time of demotion or promotion As above, we have process context at time of promotion. > and any workaround for that requires some > hacks, such as mapping the page to cpuset (what is the right solution for > shared pages?) or adding NUMA locality handling to memcg. It sounds natural to me to add NUMA nodes restriction to memcg. Best Regards, Huang, Ying
Powered by blists - more mailing lists