linux-kernel - Time accounting difference under high IO interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20180814195102.GA8568@ssarabia-MOBL7.amr.corp.intel.com>
Date:   Tue, 14 Aug 2018 12:51:52 -0700
From:   Solio Sarabia <solio.sarabia@...el.com>
To:     mingo@...nel.org, peterz@...radead.org, frederick@...nel.org,
        tj@...nel.org, wanpeng.li@...mail.com
Cc:     linux-kernel@...r.kernel.org, ak@...ux.intel.com,
        shiny.sebastian@...el.com, amy.l.leeland@...el.com,
        jun.nakajima@...el.com, sainath.grandhi@...el.com
Subject: Time accounting difference under high IO interrupts

Under high IO activity (storage or network), the kernel is not
accounting some cpu cycles, comparing sar vs emon (tool that accesses hw
pmu directly). The difference is higher on cores that spend most time on
idle state and are constantly waking up to handle interrupts. It happens
even with fine IRQ time accounting enabled (CONFIG_IRQ_TIME_ACCOUNTING).

After playing with timer subsytem options (periodick ticks, idle
tickless, full tickless), time and stats accounting, and jiffie values,
the issue persists. Cycles lost are not accounted on other cores as
'extra' util. Example with linux 4.15.18 baremetal, xeon v4 broadwell,
driving network traffic:

           sar    emon   emon-sar   intrs/sec
core12    5.00   11.70   6.70       29,302
core17   19.07   23.16   4.09       17,345
core20   19.41   23.11   3.70       16,578

Based on how kernel accounts time:
Do you have an idea why a high number of intrs affect time accounting?

Thanks,
-Solio