Messages in this thread | | | From | Zi Yan <> | Subject | Re: [PATCH 0/5] Page demotion for memory reclaim | Date | Thu, 21 Mar 2019 14:20:51 -0700 |
| |
On 21 Mar 2019, at 13:01, Keith Busch wrote:
> The kernel has recently added support for using persistent memory as > normal RAM: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c221c0b0308fd01d9fb33a16f64d2fd95f8830a4 > > The persistent memory is hot added to nodes separate from other memory > types, which makes it convenient to make node based memory policies. > > When persistent memory provides a larger and cheaper address space, but > with slower access characteristics than system RAM, we'd like the kernel > to make use of these memory-only nodes as a migration tier for pages > that would normally be discared during memory reclaim. This is faster > than doing IO for swap or page cache, and makes better utilization of > available physical address space. > > The feature is not enabled by default. The user must opt-in to kernel > managed page migration by defining the demotion path. In the future, > we may want to have the kernel automatically create this based on > heterogeneous memory attributes and CPU locality. >
Cc more people here.
Thank you for the patchset. This is definitely useful when we have larger PMEM backing existing DRAM. I have several questions:
1. The name of “page demotion” seems confusing to me, since I thought it was about large pages demote to small pages as opposite to promoting small pages to THPs. Am I the only one here?
2. For the demotion path, a common case would be from high-performance memory, like HBM or Multi-Channel DRAM, to DRAM, then to PMEM, and finally to disks, right? More general case for demotion path would be derived from the memory performance description from HMAT[1], right? Do you have any algorithm to form such a path from HMAT?
3. Do you have a plan for promoting pages from lower-level memory to higher-level memory, like from PMEM to DRAM? Will this one-way demotion make all pages sink to PMEM and disk?
4. In your patch 3, you created a new method migrate_demote_mapping() to migrate pages to other memory node, is there any problem of reusing existing migrate_pages() interface?
5. In addition, you only migrate base pages, is there any performance concern on migrating THPs? Is it too costly to migrate THPs?
Thanks.
[1] https://lwn.net/Articles/724562/
-- Best Regards, Yan Zi [unhandled content-type:application/pgp-signature] | |