Hi Kirill, Thanks a lot for the feedback. On 8/9/2022 6:04 PM, Kirill A. Shutemov wrote: > On Mon, Aug 08, 2022 at 10:56:45PM +0800, Aaron Lu wrote: >> This is an early RFC. While all reviews are welcome, reviewing this code >> now will be a waste of time for the x86 subsystem maintainers. I would, >> however, appreciate a preliminary review from the folks on the to and cc >> list. I'm posting it to the list in case anyone else is interested in >> seeing this early version. > > Last time[1] I tried to merge pages back in direct mapping it lead to > substantial performance regression for some workloads. I cannot find the > report right now, but I remember it was something graphics related. > Do you happen to remember the workload name? I can try running it. > Have you done any performance evaluation? > Not yet, I was mostly concentrating on correctness. In addition to the graphics workload, do you have anything else in mind that may be sensitive to such a change? I think maybe I can run patch4's mode0 test with and without this merge functionality and see how performance would change since mode0 is essentially doing various set_memory_X() calls on different cpus simultaneously which can trigger a lot of splits and merges. Sounds good? > My take away was that the merge has to be batched. Like log where changes > to direct mapping happens and come back to then and merge when the number > of changes cross some limit. > Appreciate your suggestion. > Also I don't see you handling set_memory_4k(). Huh? > Ah Right, I missed that. Currently set_memory_4k() is not specially handled and can be mistakenly merged. Will fix this in later versions. > [1] https://lore.kernel.org/lkml/20200416213229.19174-1-kirill.shutemov@xxxxxxxxxxxxxxx/ > Thanks!
