| Message ID | 20210715055145.195411-1-ying.huang@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Migrate Pages in lieu of discard | expand |
On Thu, 15 Jul 2021 13:51:36 +0800 Huang Ying <ying.huang@intel.com> wrote: > The full series is also available here: > > https://github.com/hying-caritas/linux/tree/automigrate-20210715 > > The changes since the last post are as follows, > > * Reduce code duplication via move common demotion condition code > into can_demote_anon_pages() per Wei's comments. > > -- > > We're starting to see systems with more and more kinds of memory such > as Intel's implementation of persistent memory. > > Let's say you have a system with some DRAM and some persistent memory. > Today, once DRAM fills up, reclaim will start and some of the DRAM > contents will be thrown out. Allocations will, at some point, start > falling over to the slower persistent memory. > > That has two nasty properties. First, the newer allocations can end > up in the slower persistent memory. Second, reclaimed data in DRAM > are just discarded even if there are gobs of space in persistent > memory that could be used. > > This set implements a solution to these problems. At the end of the > reclaim process in shrink_page_list() just before the last page > refcount is dropped, the page is migrated to persistent memory instead > of being dropped. > > While I've talked about a DRAM/PMEM pairing, this approach would > function in any environment where memory tiers exist. > > This is not perfect. It "strands" pages in slower memory and never > brings them back to fast DRAM. Huang Ying has follow-on work which > repurposes autonuma to promote hot pages back to DRAM. > > This is also all based on an upstream mechanism that allows > persistent memory to be onlined and used as if it were volatile: > > http://lkml.kernel.org/r/20190124231441.37A4A305@viggo.jf.intel.com > > We have tested the patchset with the postgresql and pgbench. On a > 2-socket server machine with DRAM and PMEM, the kernel with the > patchset can improve the score of pgbench up to 22.1% compared with > that of the DRAM only + disk case. This comes from the reduced disk > read throughput (which reduces up to 70.8%). The [0/n] description talks a lot about PMEM, but the patches themselves are all about NUMA nodes. I assume that what ties this together is that the PMEM tends to be organized as a NUMA node on its own, and that by enabling migrate-to-remote-node-during-reclaim, we get this PMEM behaviour as a desired side-effect? IOW, perhaps this [0/n] description could explain the linkage between PMEM and NUMA nodes more explicitly. Secondly... at some point it just won't make sense to migrate pages to a remote node because that remote node isn't remote enough. I mean, if accessing the remote node is 2% slower than the local node, it's best to just reclaim the page rather than going to the effort of migrating it around? And I assume the patchset doesn't (yet) attempt to make this judgement? Thirdly, the final patch which makes the feature off-by-default is a concern. I expect this will cause the new feature to have much less testing (functional and performance). We could make it default-on for now, then flip that to default-off after 5.14-rc5 (for example). That will help, but is a bit lame. Is it not possible for the kernel to look at the overall system layout and make an educated guess as to whether this system will benefit? And I see this, from the [9/9] changelog: : The benefits are truly workload-based and *not* hardware-based. We do : not believe that there is a viable threshold where certain hardware : configurations should have this mechanism enabled while others do not. so... why not simply enable the thing for all systems and be done with it? What sort of downsides are you anticipating? We could of course include an emergency-off knob, but hoping that it won't need to be used. Finally, having a feature which is good for some workloads, bad for others and which contains a system-wide enable knob is really quite sad. It requires a lot of work from each and every operator in the world! They must experimentally run their workloads both with and without, and determine which is best. And they should rerun this testing periodically as userspace and the kernel evolve, to determine whether their earlier experimenting holds true. And what happens if workload #1 wins and workload #2 loses? And of course, many operators simply won't do all of this and they'll run slower, or will miss out of benefits. What can we do to relieve our users of all of this?
On 7/15/21 12:38 PM, Andrew Morton wrote: > On Thu, 15 Jul 2021 13:51:36 +0800 Huang Ying <ying.huang@intel.com> wrote: >> We have tested the patchset with the postgresql and pgbench. On a >> 2-socket server machine with DRAM and PMEM, the kernel with the >> patchset can improve the score of pgbench up to 22.1% compared with >> that of the DRAM only + disk case. This comes from the reduced disk >> read throughput (which reduces up to 70.8%). > > The [0/n] description talks a lot about PMEM, but the patches > themselves are all about NUMA nodes. I assume that what ties this > together is that the PMEM tends to be organized as a NUMA node on its > own, and that by enabling migrate-to-remote-node-during-reclaim, we get > this PMEM behaviour as a desired side-effect? Yes, an assumption of this whole thing is that there are uniform performance capabilities within a NUMA node. ACPI systems that implement the HMAT table require that each proximity domain (PXM) have these uniform capabilities. This works out great since PXMs are so closely translated to NUMA nodes. > IOW, perhaps this [0/n] description could explain the linkage between > PMEM and NUMA nodes more explicitly. Sure, we can do that. > Secondly... at some point it just won't make sense to migrate pages to > a remote node because that remote node isn't remote enough. I mean, if > accessing the remote node is 2% slower than the local node, it's best > to just reclaim the page rather than going to the effort of migrating > it around? One thing to keep in mind is that these migrations are *cheap*. Because of the point where the migration is done near the end of the reclaim process the page should be unmapped. The expensive part like TLB shootdowns don't need to happen. But, yes, you're right. There are going to be situations where it would have been better to reclaim the page. > And I assume the patchset doesn't (yet) attempt to make this judgement? Correct. The assumption is that, on average, having something in slower memory is better than having it out of memory. > Thirdly, the final patch which makes the feature off-by-default is a > concern. I expect this will cause the new feature to have much less > testing (functional and performance). We could make it default-on for > now, then flip that to default-off after 5.14-rc5 (for example). That > will help, but is a bit lame. Is it not possible for the kernel to > look at the overall system layout and make an educated guess as to > whether this system will benefit? Unfortunately, no. It's highly workload dependent. I see it a lot like autonuma or khugepaged/THP: there are going to be some big upsides, but we're under no illusions that the wins will be universal. I'd actually be quite happy to flip it to be default-on all the time. But, I think I'll be a lot more confident about it once we have the "promotion" side of the equation merged as well: https://lwn.net/Articles/835402/ > And I see this, from the [9/9] changelog: > > : The benefits are truly workload-based and *not* hardware-based. We do > : not believe that there is a viable threshold where certain hardware > : configurations should have this mechanism enabled while others do not. > > so... why not simply enable the thing for all systems and be done with > it? What sort of downsides are you anticipating? We could of course > include an emergency-off knob, but hoping that it won't need to be > used. The worst case scenario is that an important workload starts up, eats a bunch of RAM and then goes idle, maybe during off-peak workload hours. During the night, a bunch of batch jobs kick in and evict some of that workload's data to PMEM. The workload spools up again the next morning and is hampered by the slower PMEM when there's lots of DRAM available. This will be helped by the autonuma-based promotion once it's in place. > Finally, having a feature which is good for some workloads, bad for > others and which contains a system-wide enable knob is really quite > sad. It requires a lot of work from each and every operator in the > world! They must experimentally run their workloads both with and > without, and determine which is best. And they should rerun this > testing periodically as userspace and the kernel evolve, to determine > whether their earlier experimenting holds true. And what happens if > workload #1 wins and workload #2 loses? > > And of course, many operators simply won't do all of this and they'll > run slower, or will miss out of benefits. What can we do to relieve > our users of all of this? I think this is a much bigger question than this patch set. It's basically the tale of /proc/sys/vm/* or /sys/kernel/mm. Some workloads win with transparent_hugepage/enabled=always, some lose. Some win with zone_reclaim_mode=7, some prefer zone_reclaim_mode=0. The end game for auto-migration is to on by default, wherever these hardware configurations show up. Just like THP, I expect this to be broadly useful. But, given the breadth of our user base, I also expect it to be nasty for a minority of users. They'll need a way to turn it off, and hopefully they'll also provide feedback so that, if possible, we can improve the default behavior and bring them back into the fold.
On Thu, Jul 15, 2021 at 02:42:07PM -0700, Dave Hansen wrote: > The end game for auto-migration is to on by default, wherever these > hardware configurations show up. Just like THP, I expect this to be > broadly useful. But, given the breadth of our user base, I also expect > it to be nasty for a minority of users. They'll need a way to turn it > off, and hopefully they'll also provide feedback so that, if possible, > we can improve the default behavior and bring them back into the fold. ... or if the THP experience is anything to go by, they continue to shout loudly about how borken it is for a decade ;-(
Andrew Morton <akpm@linux-foundation.org> writes: > On Thu, 15 Jul 2021 13:51:36 +0800 Huang Ying <ying.huang@intel.com> wrote: > > The [0/n] description talks a lot about PMEM, but the patches > themselves are all about NUMA nodes. I assume that what ties this > together is that the PMEM tends to be organized as a NUMA node on its > own, and that by enabling migrate-to-remote-node-during-reclaim, we get > this PMEM behaviour as a desired side-effect? > > IOW, perhaps this [0/n] description could explain the linkage between > PMEM and NUMA nodes more explicitly. Hi, Andrew, I have added some words in the [0/9] description to link PMEM and NUMA nodes. The updated description is as below. Can you take a look at it? Best Regards, Huang, Ying --------------------------8<----------------------------------- We're starting to see systems with more and more kinds of memory such as Intel's implementation of persistent memory. Let's say you have a system with some DRAM and some persistent memory. Today, once DRAM fills up, reclaim will start and some of the DRAM contents will be thrown out. Allocations will, at some point, start falling over to the slower persistent memory. That has two nasty properties. First, the newer allocations can end up in the slower persistent memory. Second, reclaimed data in DRAM are just discarded even if there are gobs of space in persistent memory that could be used. This patchset implements a solution to these problems. At the end of the reclaim process in shrink_page_list() just before the last page refcount is dropped, the page is migrated to persistent memory instead of being dropped. While I've talked about a DRAM/PMEM pairing, this approach would function in any environment where memory tiers exist. This is not perfect. It "strands" pages in slower memory and never brings them back to fast DRAM. Huang Ying has follow-on work which repurposes autonuma to promote hot pages back to DRAM. This is also all based on an upstream mechanism that allows persistent memory to be onlined and used as if it were volatile: http://lkml.kernel.org/r/20190124231441.37A4A305@viggo.jf.intel.com With that, the DRAM and PMEM in each socket will be represented as 2 separate NUMA nodes, with the CPUs sit in the DRAM node. So the general inter-NUMA demotion mechanism introduced in the patchset can migrate the cold DRAM pages to the PMEM node. We have tested the patchset with the postgresql and pgbench. On a 2-socket server machine with DRAM and PMEM, the kernel with the patchset can improve the score of pgbench up to 22.1% compared with that of the DRAM only + disk case. This comes from the reduced disk read throughput (which reduces up to 70.8%). == Open Issues == * Memory policies and cpusets that, for instance, restrict allocations to DRAM can be demoted to PMEM whenever they opt in to this new mechanism. A cgroup-level API to opt-in or opt-out of these migrations will likely be required as a follow-on. * Could be more aggressive about where anon LRU scanning occurs since it no longer necessarily involves I/O. get_scan_count() for instance says: "If we have no swap space, do not bother scanning anon pages"
On Fri, 16 Jul 2021 11:32:09 +0800 "Huang, Ying" <ying.huang@intel.com> wrote: > Andrew Morton <akpm@linux-foundation.org> writes: > > > On Thu, 15 Jul 2021 13:51:36 +0800 Huang Ying <ying.huang@intel.com> wrote: > > > > The [0/n] description talks a lot about PMEM, but the patches > > themselves are all about NUMA nodes. I assume that what ties this > > together is that the PMEM tends to be organized as a NUMA node on its > > own, and that by enabling migrate-to-remote-node-during-reclaim, we get > > this PMEM behaviour as a desired side-effect? > > > > IOW, perhaps this [0/n] description could explain the linkage between > > PMEM and NUMA nodes more explicitly. > > Hi, Andrew, > > I have added some words in the [0/9] description to link PMEM and NUMA > nodes. The updated description is as below. Can you take a look at it? > > ... > > With that, the DRAM and PMEM in each socket will be represented as 2 > separate NUMA nodes, with the CPUs sit in the DRAM node. So the > general inter-NUMA demotion mechanism introduced in the patchset can > migrate the cold DRAM pages to the PMEM node. > Bingo, thanks.