From: Bernhard Voelker <m...@bernhard-voelker.de> Subject: Re: [PATCH] du: add flag to show cache memory usage Date: Mon, 7 Apr 2025 16:40:10 +0200
> On 4/7/25 01:49, Matteo Croce wrote: >> Under Linux, add a --memory flag which allows to show cache memory >> usage >> of files: >> >> $ truncate -s100M file >> $ du file >> 0 file >> $ dd status=none bs=1M count=5 if=file of=/dev/null >> $ du --memory --human file >> 10M file >> $ dd status=none bs=1M skip=30 count=5 if=file of=/dev/null >> $ du --memory --human file >> 21M file >> $ cat file >/dev/null >> $ du --memory --human file >> 100M file > > Thanks for the patch - with that we can discuss about something > concrete. > > Still, I'm personally quite reluctant about adding it due to the > following > reasons: > > a) the functionality is only available on GNU/Linux - as discussed > already. > https://lists.gnu.org/archive/html/coreutils/2025-03/msg00017.html This --memory patch uses cachestat system call for efficiency. Linux introduced cachestat system call as improved version of mincore system call. https://lwn.net/Articles/914997/ We can implement --memory option (or mu command) on the other paltform with traditional mincore system call. What I could find: FreeBSD: https://man.freebsd.org/cgi/man.cgi?query=mincore NetBSD: https://man.netbsd.org/mincore.2 OpenBSD: https://man.openbsd.org/OpenBSD-6.3/mincore.2 Solaris: https://docs.oracle.com/cd/E88353_01/html/E37841/mincore-2.html AIX: https://www.ibm.com/docs/en/aix/7.1?topic=m-mincore-subroutine It seems that Hurd doesn't have mincore yet. However, it is on the TODO list: http://www.gnu.msn.by/prep/tasks.hurd.html We can say the functionality is available on various platforms. Masatake YAMATO > b) the du(1) utility is about file space usage on the file system. > Thus, adding code for how a file is represented in certain kernel > memory > areas just because the output shall be similar to du(1) sounds quite > off to me. With that in mind, one could also add wc(1) functionality > into du(1). > > I can see that the name 'mu' - as suggested initially, see link above > - would > fit quite well into the naming pattern of du(1), and (GNU/Linux) users > would > learn that very fast, but as the functionality is not portable the GNU > coreutils > seem the wrong place for it. > > Therefore, I'm 10:90 for adding this. > > Have a nice day, > Berny >
