On Tue, Apr 26, 2022 at 03:55:36PM +0800, ying.huang@xxxxxxxxx wrote: > On Mon, 2022-04-25 at 16:45 +0530, Jagdish Gediya wrote: > > On Sun, Apr 24, 2022 at 11:19:53AM +0800, ying.huang@xxxxxxxxx wrote: > > > On Sat, 2022-04-23 at 01:25 +0530, Jagdish Gediya wrote: > > > > Some systems(e.g. PowerVM) can have both DRAM(fast memory) only > > > > NUMA node which are N_MEMORY and slow memory(persistent memory) > > > > only NUMA node which are also N_MEMORY. As the current demotion > > > > target finding algorithm works based on N_MEMORY and best distance, > > > > it will choose DRAM only NUMA node as demotion target instead of > > > > persistent memory node on such systems. If DRAM only NUMA node is > > > > filled with demoted pages then at some point new allocations can > > > > start falling to persistent memory, so basically cold pages are in > > > > fast memor (due to demotion) and new pages are in slow memory, this > > > > is why persistent memory nodes should be utilized for demotion and > > > > dram node should be avoided for demotion so that they can be used > > > > for new allocations. > > > > > > > > Current implementation can work fine on the system where the memory > > > > only numa nodes are possible only for persistent/slow memory but it > > > > is not suitable for the like of systems mentioned above. > > > > > > Can you share the NUMA topology information of your machine? And the > > > demotion order before and after your change? > > > > > > Whether it's good to use the PMEM nodes as the demotion targets of the > > > DRAM-only node too? > > > > $ numactl -H > > available: 2 nodes (0-1) > > node 0 cpus: 0 1 2 3 4 5 6 7 > > node 0 size: 14272 MB > > node 0 free: 13392 MB > > node 1 cpus: > > node 1 size: 2028 MB > > node 1 free: 1971 MB > > node distances: > > node 0 1 > > 0: 10 40 > > 1: 40 10 > > > > 1) without N_DEMOTION_TARGETS patch series, 1 is demotion target > > for 0 even when 1 is DRAM node and there is no demotion targets for 1. > > > > $ cat /sys/bus/nd/devices/dax0.0/target_node > > 2 > > $ > > # cd /sys/bus/dax/drivers/ > > :/sys/bus/dax/drivers# ls > > device_dax kmem > > :/sys/bus/dax/drivers# cd device_dax/ > > :/sys/bus/dax/drivers/device_dax# echo dax0.0 > unbind > > :/sys/bus/dax/drivers/device_dax# echo dax0.0 > ../kmem/new_id > > :/sys/bus/dax/drivers/device_dax# numactl -H > > available: 3 nodes (0-2) > > node 0 cpus: 0 1 2 3 4 5 6 7 > > node 0 size: 14272 MB > > node 0 free: 13380 MB > > node 1 cpus: > > node 1 size: 2028 MB > > node 1 free: 1961 MB > > node 2 cpus: > > node 2 size: 0 MB > > node 2 free: 0 MB > > node distances: > > node 0 1 2 > > 0: 10 40 80 > > 1: 40 10 80 > > 2: 80 80 10 > > > > This looks like a virtual machine, not a real machine. That's > unfortunate. I am looking forward to a real issue, not a theoritical > possible issue. > > > 2) Once this new node brought online, without N_DEMOTION_TARGETS > > patch series, 1 is demotion target for 0 and 2 is demotion target > > for 1. > > > > With this patch series applied, > > 1) No demotion target for either 0 or 1 before dax device is online > > 2) 2 is demotion target for both 0 and 1 after dax device is online. > > > > So with your change, if a node hasn't N_DEMOTION_TARGETS, it will become > a top-level demotion source even if it hasn't N_CPU? If so, I cannot > clear N_DEMOTION_TARGETS for a node in middle or bottom level? Yes, only N_MEMORY node also become demotion source because it is not N_DEMOTION_TARGETS. You can clear N_DEMOTION_TARGETS from middle or bottom but in that case, as the implementation works based on the passes, cleared node will not be found as demotion target hence demotion target will not be found for it, but does it make sense to use faster persistent memory as demotion target leaving slowerer persistent memory out of demotion list, if not, then it is not an issue. > Best Regards, > Huang, Ying > > > > > [snip] > > >
