I found a discussion on ServerFault that discusses this. Basically,
$ sudo grep huge /proc/*/numa_maps
/proc/4131/numa_maps:80000000 default file=/anon_hugepage\040(deleted) huge anon=4 dirty=4 N0=3 N1=1
/proc/4131/numa_maps:581a00000 default file=/anon_hugepage\040(deleted) huge anon=258 dirty=258 N0=150 N1=108
/proc/4131/numa_maps:7f6c40400000 default file=/anon_hugepage\040(deleted) huge
/proc/4131/numa_maps:7f6ce5000000 default file=/anon_hugepage\040(deleted) huge anon=1 dirty=1 N0=1
/proc/4153/numa_maps:80000000 default file=/anon_hugepage\040(deleted) huge anon=7 dirty=7 N0=6 N1=1
/proc/4153/numa_maps:581a00000 default file=/anon_hugepage\040(deleted) huge anon=265 dirty=265 N0=162 N1=103
/proc/4153/numa_maps:7f3dc8400000 default file=/anon_hugepage\040(deleted) huge
/proc/4153/numa_maps:7f3e00600000 default file=/anon_hugepage\040(deleted) huge anon=1 dirty=1 N0=1
and getting the process name
$ ps 4131
PID TTY STAT TIME COMMAND
4131 ? Sl 1:08 /var/lib/jenkins/java/bin/java -jar slave.jar
$ ps 4153
PID TTY STAT TIME COMMAND
4153 ? Sl 1:09 /var/lib/jenkins/java/bin/java -jar slave.jar
will give you an idea of what processes are using huge memory.
$ grep HugePages /proc/meminfo
AnonHugePages: 1079296 kB
HugePages_Total: 4096
HugePages_Free: 3560
HugePages_Rsvd: 234
HugePages_Surp: 0
$ sudo ~/bin/counthugepages.pl 4153
273 huge pages
$ sudo ~/bin/counthugepages.pl 4131
263 huge pages
The sum of free pages (3560) plus the pages from the 2 process (273+263) equals 4096. All accounted for!
The perl script to sum the dirty= fields is here:
https://serverfault.com/questions/527085/linux-non-transparent-per-process-hugepage-accounting/644471#644471
@Stephen_Kitt reports that "Debian 6 was current in 2011, with kernel 2.6.32, and didn’t have transparent hugepages, it had hugetlbfs. Debian used “madvise” from 2.6.38 to 4.13, where it switched to “always”. Thus Debian 7 through 9 use “madvise”, while Debian 10 will use “always”."
Some installs of Ubuntu on servers are reported as enabling hugepages for all apps. (That is, web search finds some users asking how to disable huge pages on their Ubuntu installs :-). ). Some of these mention EC2 images specifically. @couling reports their Ubuntu server on AWS does not enable hugepages for all apps. So it seemed a bit difficult to answer for Ubuntu Server. Then I found the AskUbuntu question, "Where can I get the [Ubuntu] 11.04 kernel .config file?".
In Ubuntu 16.04, specific builds are available e.g. for AWS (Amazon Web Services). Looking at kernel version 4.4.0-125.150, the AWS kernel enabled TRANSPARENT_HUGEPAGES_ALWAYS. However the generic kernel did not.
In Ubuntu 18.04, the generic kernel still did not enable TRANSPARENT_HUGEPAGES_ALWAYS.
Ubuntu 11.10 was released in October 2011, and might be the first release with TRANSPARENT_HUGEPAGES enabled. It appears to not enable TRANSPARENT_HUGEPAGES_ALWAYS.
I think current SLES - SUSE Linux Enterprise version 15, and at least versions 12 and 11 - also match the current RHEL setting. I.e. they enable transparent hugepages for all apps.
[By implication: was LWN.net correct here, or not?]
All three of the bug reports cited by kernel developer Mel Gorman, involved a web browser affected when copying to a slow USB stick or SD card. So that point of the article is well-founded. One of the reports was "internally in SUSE". In the other two cases, it is not immediately clear where the kernel configuration came from.
As @couling pointed out, if the sysfs file shows [madvise], you should not say that THP is disabled altogether. It only means that THP will not applied automatically for all apps, as in the [always] case. At least to some extent, the LWN article glossed over the distinction - the distinction between "the transparent huge pages feature is built into the kernel", and "the page fault handler will attempt to allocate a huge page", regarding a web browser which is known not to use MADV_HUGEPAGE. It is clear that most distributors enable the former, but the latter claim is not so clear to me.
I notice that according to the source code, when you choose to enable the kernel config TRANSPARENT_HUGEPAGE, the default config is (and has always been) to enable TRANSPARENT_HUGEPAGE_ALWAYS.
Perhaps LWN mis-interpreted this. Or perhaps there was a brief surge of distribution kernels released with TRANSPARENT_HUGEPAGE_ALWAYS, which were then reverted after discovering the range of potential disadvantages :-). I am not sure.
Best Answer
Huge pages would be useful in a situation where you needed a huge amount of information to be written in the same block. It can relate to the strategy for disk writes and can be significant for caching. Like all configuration options, it makes no sense if your use case does not fit.
So the answer is, workload that actually needs a huge ton of data in the same block would benefit from huge pages. If the data is so large it would not be able to fit, but would have to be broken up into numerous page files, and the sheer number of those would be too many to handle or bad for some reason, and the lower number of larger files is preferable - there is your case for huge page files.
In practical terms, I have never come across any need for it but I know from managing caches - it is a real thing and someone, somewhere, could benefit from huge pages.