On 02/08/2018 11:19 AM, Alexander Dahl wrote:
> On Thu, Feb 08, 2018 at 10:17:31AM +0100, Marc Kleine-Budde wrote:
>> Have you enabled CONFIG_TASK_XACCT and CONFIG_TASK_IO_ACCOUNTING?
> 
> Didn't have that before. I get some values now, although I'm not sure
> how to interpret those. I should probably look in the htop
> documentation again. But thanks for the hint, I guess htop can show
> even more interesting things, I did not know it can, yet. :-)

Luckily I've recently collected all needed information:

> RCHAR - Number of bytes the process has read
> WCHAR - Number of bytes the process has written
> SYSCR - Number of read(2) syscalls for the process
> SYSCW - Number of write(2) syscalls for the process
> RBYTES - Bytes of read(2) I/O for the process
> WBYTES - Bytes of write(2) I/O for the process
> CNCLWB - Bytes of cancelled write(2) I/O
> 
> IO_READ_RATE - The I/O rate of read(2) in bytes per second for the
>                process
> IO_WRITE_RATE - The I/O rate of write(2) in bytes per second for the
>                 process
> IO_RATE - Total I/O rate in bytes per second
> 
> However if you want machine readable output, you have two options:
> 
> 1)
> Parse /proc/$PID/io directly, which correspond to the absolute numbers
> from htop. The *_RATE values are calculated by htop from the absolute
> numbers.
> 
> See man-page of proc(5) for more information about /proc/$PID/io:
> 
>> >               rchar: characters read
>> >                      The  number of bytes which this task has caused to
>> >                      be read from storage.  This is simply the  sum  of
>> >                      bytes  which  this  process  passed to read(2) and
>> >                      similar system calls.  It includes things such  as
>> >                      terminal  I/O  and is unaffected by whether or not
>> >                      actual physical disk I/O was  required  (the  read
>> >                      might have been satisfied from pagecache).
>> > 
>> >               wchar: characters written
>> >                      The number of bytes which this task has caused, or
>> >                      shall  cause  to  be  written  to  disk.   Similar
>> >                      caveats apply here as with rchar.
> 
> Counts all read/write done through files (_including_ pseudo files like
> /dev/zero, /dev/null, named pipes).
> 
>> >               syscr: read syscalls
>> >                      Attempt  to  count  the  number of read I/O opera‐
>> >                      tions—that is, system calls such  as  read(2)  and
>> >                      pread(2).
>> > 
>> >               syscw: write syscalls
>> >                      Attempt  to  count  the number of write I/O opera‐
>> >                      tions—that is, system calls such as  write(2)  and
>> >                      pwrite(2).
>> > 
>> >               read_bytes: bytes read
>> >                      Attempt  to  count  the number of bytes which this
>> >                      process really did cause to be  fetched  from  the
>> >                      storage  layer.  This is accurate for block-backed
>> >                      filesystems.
>> > 
>> >               write_bytes: bytes written
>> >                      Attempt to count the number of  bytes  which  this
>> >                      process caused to be sent to the storage layer.
> 
> Accounting on MTD devices is not accurate for these two.
> 
>> >               cancelled_write_bytes:
>> >                      The big inaccuracy here is truncate.  If a process
>> >                      writes 1MB to a file and then deletes the file, it
>> >                      will  in  fact  perform  no writeout.  But it will
>> >                      have been accounted as having caused 1MB of write.
>> >                      In  other  words: this field represents the number
>> >                      of bytes which this process caused to not  happen,
>> >                      by  truncating pagecache.  A task can cause "nega‐
>> >                      tive" I/O too.  If this task truncates some  dirty
>> >                      pagecache,  some  I/O  which another task has been
>> >                      accounted for (in its  write_bytes)  will  not  be
>> >                      happening.
>> > 
>> >               Note:  In  the  current  implementation, things are a bit
>> >               racy on 32-bit systems: if process A  reads  process  B's
>> >               /proc/[pid]/io  while  process B is updating one of these
>> >               64-bit counters, process  A  could  see  an  intermediate
>> >               result.
>> > 
>> >               Permission  to  access  this file is governed by a ptrace
>> >               access   mode   PTRACE_MODE_READ_FSCREDS    check;    see
>> >               ptrace(2).
> 
> 2)
> Use the netlink bases taststats interface, which gives you the same
> information, but uses far less system resources.
> 
> See:
> http://lxr.bootlin.com/linux/latest/source/Documentation/accounting/taskstats.txt
> http://lxr.bootlin.com/linux/latest/source/Documentation/accounting/taskstats-struct.txt
> https://stackoverflow.com/questions/30617368/sending-netlink-taskstats-message-using-libnl-3

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |