Mike Kravetz <mike.kravetz@xxxxxxxxxx> writes: > On 05/17/2018 01:35 AM, Huang, Ying wrote: >> From: Huang Ying <ying.huang@xxxxxxxxx> >> >> This is to take better advantage of general huge page clearing >> optimization (c79b57e462b5d, "mm: hugetlb: clear target sub-page last >> when clearing huge page") for hugetlbfs. In the general optimization >> patch, the sub-page to access will be cleared last to avoid the cache >> lines of to access sub-page to be evicted when clearing other >> sub-pages. This works better if we have the address of the sub-page >> to access, that is, the fault address inside the huge page. So the >> hugetlbfs no page fault handler is changed to pass that information. >> This will benefit workloads which don't access the begin of the >> hugetlbfs huge page after the page fault under heavy cache contention >> for shared last level cache. >> >> The patch is a generic optimization which should benefit quite some >> workloads, not for a specific use case. To demonstrate the performance >> benefit of the patch, we tested it with vm-scalability run on >> hugetlbfs. >> >> With this patch, the throughput increases ~28.1% in vm-scalability >> anon-w-seq test case with 88 processes on a 2 socket Xeon E5 2699 v4 >> system (44 cores, 88 threads). The test case creates 88 processes, >> each process mmaps a big anonymous memory area with MAP_HUGETLB and >> writes to it from the end to the begin. For each process, other >> processes could be seen as other workload which generates heavy cache >> pressure. At the same time, the cache miss rate reduced from ~36.3% >> to ~25.6%, the IPC (instruction per cycle) increased from 0.3 to 0.37, >> and the time spent in user space is reduced ~19.3%. >> > > Agree with Michal that commit message looks better. > > I went through updated patch with haddr naming so, > Reviewed-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > still applies. Thanks! Best Regards, Huang, Ying
