On Mon, Feb 10, 2025 at 10:47:58AM -0500, Gregory Price wrote: > On Mon, Feb 10, 2025 at 04:17:41PM +0900, Byungchul Park wrote: > > On Mon, Feb 10, 2025 at 01:00:02AM -0500, Gregory Price wrote: > > > > > > You can probably actually (maybe?) collect data on this today - but > > > you still have to contend with #2 and #3. > > > > Ah. You seem to mean those works should be serialized. Right? If it > > should be for some reason, then it could be sensible. > > > > I'm suggesting that there isn't a strong reason (yet) to consider such a > complicated change. As Willy has said, it's a fairly fundamental change > for a single-reason (CXL), which does not bode well for its acceptance. I have observed performance difference depending on page table's placement between DRAM and slow tier, that doesn't have to be CXL memory. We should place page table in DRAM as long as possible, but when not possible, we could do either recaiming DRAM for them or temporarily place them in slow tier and move to DRAM for better performance. But yes. If slow tier is *NEVER* allowed to be huge, then reclaiming DRAM would always work. This topic is valid only for the other case. > Honestly trying to save you some frustration. It would behoove you to > find stronger reasons (w/ data) or consider different solutions. Right > now there are stronger, simplers solutions to the ZONE_NORMAL capacity > issue (struct page resize, huge pages) for possible capacities. > > I also think someone should actively ask whether `struct page` can be > hosted on remote memory without performance loss. I may look into this. JFYI, struct page, page table, and kernel stack were just example. Let's exclude ones that you don't think are feasible. However, I'd like to tell at least page table is an interesting kernel object in the topic. Byungchul > ~Gregory
