On Wed, Apr 09, 2014 at 02:49:55PM +0200, Denys Vlasenko wrote:
> > I doubt that users are interested in such random accounting. They want
> > to know either:
> >
> > 1) how much time was spent waiting on IO by the whole system
>
> Hmm, I think I just said the same thing :)
>
> > 2) how much time
On Mon, Apr 7, 2014 at 8:17 PM, Frederic Weisbecker wrote:
> The following example displays all the nonsense of that stat:
>
> CPU 0 CPU 1
>
> task A block on IO...
> task B runs for 1 min ...
> task A completes IO
>
> So in the above we've been wait
On Sat, Apr 05, 2014 at 04:56:54PM +0200, Denys Vlasenko wrote:
> On Sat, Apr 5, 2014 at 12:08 PM, Frederic Weisbecker
> wrote:
> >> > Iowait makes sense but not per cpu. Eventually it's a global
> >> > stat. Or per task.
> >>
> >> There a lot of situations where admins want to know
> >> how much
On Sat, Apr 5, 2014 at 12:08 PM, Frederic Weisbecker wrote:
>> > Iowait makes sense but not per cpu. Eventually it's a global
>> > stat. Or per task.
>>
>> There a lot of situations where admins want to know
>> how much, on average, their CPUs are idle because
>> they wait for IO.
>>
>> If you are
On Fri, Apr 04, 2014 at 07:02:43PM +0200, Denys Vlasenko wrote:
> On Fri, Apr 4, 2014 at 6:03 PM, Frederic Weisbecker
> wrote:
> >> However, if we would put ourselves into admin's seat, iowait
> >> immediately starts to make sense: for admin, the system state
> >> where a lot of CPU time is genui
On Fri, Apr 4, 2014 at 6:03 PM, Frederic Weisbecker wrote:
>> However, if we would put ourselves into admin's seat, iowait
>> immediately starts to make sense: for admin, the system state
>> where a lot of CPU time is genuinely idle is qualitatively different
>> form the state where a lot of CPU t
Hi Guys,
You and Hidetoshi have sent a few patches with very detailed changelogs
and it's going to be hard to synthesize. So my reviews are going to be a
bit chaotic, sorry for that in advance.
On Wed, Apr 02, 2014 at 09:35:47PM +0200, Denys Vlasenko wrote:
> On Mon, Mar 31, 2014 at 4:08 AM, Hide
(2014/04/03 18:51), Denys Vlasenko wrote:
> On Thu, Apr 3, 2014 at 9:02 AM, Hidetoshi Seto
> wrote:
[PROBLEM 2]: broken iowait accounting.
As historical nature, cpu's idle time was accounted as either
idle or iowait depending on the presence of tasks blocked by
I/O. No one
On Thu, Apr 3, 2014 at 9:02 AM, Hidetoshi Seto
wrote:
>>> [PROBLEM 2]: broken iowait accounting.
>>>
>>> As historical nature, cpu's idle time was accounted as either
>>> idle or iowait depending on the presence of tasks blocked by
>>> I/O. No one complain about it for a long time. However:
>>>
>>
(2014/04/03 4:35), Denys Vlasenko wrote:
> On Mon, Mar 31, 2014 at 4:08 AM, Hidetoshi Seto
> wrote:
>> There are 2 problems:
>>
>> [PROBLEM 1]: there is no exclusive control.
>>
>> It is easy to understand that there are 2 different cpu - an
>> observing cpu where running a program observing idle
On Mon, Mar 31, 2014 at 4:08 AM, Hidetoshi Seto
wrote:
> There are 2 problems:
>
> [PROBLEM 1]: there is no exclusive control.
>
> It is easy to understand that there are 2 different cpu - an
> observing cpu where running a program observing idle cpu's stat
> and an observed cpu where performing i
This patch is 1/2 of patch set to fix an issue that idle/iowait
of /proc/stat can go backward. Originally reported by Tetsuo and
Fernando at last year, Mar 2013.
[BACKGROUNDS]: idle accounting on NO_HZ
If NO_HZ is enabled, cpu stops tick interrupt for itself before
go sleep to be idle. It means t
On 03/24/2014 01:51 PM, Hidetoshi Seto wrote:
> (2014/03/24 16:45), Preeti Murthy wrote:
>> Hi Hidetoshi,
>>
>> The patch looks good to me except the comments around the monotonicity
>> of the return value of the idle stats observer. I am unable to relate them
>> to the dependency on nr_iowait_cpu.
(2014/03/24 16:45), Preeti Murthy wrote:
> Hi Hidetoshi,
>
> The patch looks good to me except the comments around the monotonicity
> of the return value of the idle stats observer. I am unable to relate them
> to the dependency on nr_iowait_cpu.
>
> I see that when the reader queries for the idl
Hi Hidetoshi,
The patch looks good to me except the comments around the monotonicity
of the return value of the idle stats observer. I am unable to relate them
to the dependency on nr_iowait_cpu.
I see that when the reader queries for the idle stats and calls
get_cpu_idle_time_us(), the nr_iowait
This patch is 1/2 of patch set to fix an issue that idle/iowait
of /proc/stat can go backward. Originally reported by Tetsuo and
Fernando at last year, Mar 2013.
[BACKGROUNDS]: idle accounting on NO_HZ
If NO_HZ is enabled, cpu stops tick interrupt for itself before
go sleep to be idle. It means t
16 matches
Mail list logo
