On 1/10/24 16:11, John Hubbard wrote:
On 1/10/24 3:21 PM, John Hubbard wrote:
...
2) On an mTHP kernel with the latest patchsets (arm64, 64K page size), I
*think* I cannot turn off mTHP. I'm still teasing apart how much of this
is an instrumentation error, and how much is a measurement problem (with
the test suite). And maybe I'm wrong entirely. But the "never" option
doesn't seem to have an effect. Unless the latest version of the testsuite
is doing something new, sigh.
OK, it turns out that the test suite changed over to use hugetlbfs
on this version. So the performance remained high, with or without
THP settings. heh. Please disregard this part. :)
...although, this does turn out to be informative with respect to
thpmap. Because, look at this case:
Container app does this:
umount /dev/shm
mount -t tmpfs tmpfs -o huge=always /dev/shm; findmnt /dev/shm
...and then monitoring it:
# ./thpmaps --cgroup /sys/fs/cgroup --cont 128K --cont 512K --cont 1M \
--cont 2M --cont 512M --summary
file-thp-aligned-524288kB: 105906176 kB (97%)
file-thp-partial: 1415680 kB ( 1%)
file-cont-aligned-128kB: 107321600 kB (99%)
file-cont-aligned-512kB: 106886656 kB (98%)
file-cont-aligned-1024kB: 106886144 kB (98%)
file-cont-aligned-2048kB: 106883072 kB (98%)
file-cont-aligned-524288kB: 105906176 kB (97%)
So what I'm trying to say here is, it is still difficult to tell
what's going on. In particular, hugetlbfs vs. [m]THP is not yet clear.
thanks,
--
John Hubbard
NVIDIA
