On 01/30/2019 05:00 PM, Thomas Gleixner wrote:
> On Wed, 30 Jan 2019, Andrew Morton wrote:
>> On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner
>> wrote:
>>
>>> Waiman reported that on large systems with a large amount of interrupts the
>>> readout of /proc/stat takes a long time to sum up the i
On 01/30/2019 05:00 PM, Thomas Gleixner wrote:
> On Wed, 30 Jan 2019, Andrew Morton wrote:
>> On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner
>> wrote:
>>
>>> Waiman reported that on large systems with a large amount of interrupts the
>>> readout of /proc/stat takes a long time to sum up the i
On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner wrote:
> Waiman reported that on large systems with a large amount of interrupts the
> readout of /proc/stat takes a long time to sum up the interrupt
> statistics. In principle this is not a problem. but for unknown reasons
> some enterprise qua
On Wed, 30 Jan 2019, Andrew Morton wrote:
> On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner wrote:
>
> > Waiman reported that on large systems with a large amount of interrupts the
> > readout of /proc/stat takes a long time to sum up the interrupt
> > statistics. In principle this is not a pr
On 01/30/2019 07:31 AM, Thomas Gleixner wrote:
> Waiman reported that on large systems with a large amount of interrupts the
> readout of /proc/stat takes a long time to sum up the interrupt
> statistics. In principle this is not a problem. but for unknown reasons
> some enterprise quality software
Waiman reported that on large systems with a large amount of interrupts the
readout of /proc/stat takes a long time to sum up the interrupt
statistics. In principle this is not a problem. but for unknown reasons
some enterprise quality software reads /proc/stat with a high frequency.
The reason fo
6 matches
Mail list logo