Re: [RFC PATCH 0/8] rework iowait accounting

[Peter Zijlstra <peterz@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]

On Thu, Jun 26, 2014 at 06:06:23PM +0900, Hidetoshi Seto wrote:
> [Request for Comments]
> 
>   So, as the first step to solve this bunch of problems, I wrote
>   some pseudo codes for review to check my direction. These codes
>   look like usual patch set but !! _NOT_TESTED_COMPLETELY_ !!
>   Now I don't have s390/ia64/ppc test box so I didn't even check
>   these pass the compiler :-p

qemu? It'd be horridly slow I suppose. But you should be able to get a
cross compiler at the least.

>   What I want to do here is:
> 
>   - record timestamp at the end of iowait (decrement nr_iowait
>     from 1 to 0) and use it for iowait time accounting
>     (This idea is what PeterZ suggested)
> 
>   - use same strategy for basic tick-accounting, NO_HZ kernel,
>     s390 and other VIRT_CPU_ACCOUNTING architectures.
> 
>   Still I'm concerning performance impact by changing scheduler
>   core codes and also possible troubles by comparing timestamps
>   from different clocks.

So I don't _think_ the performance impact is _that_ high for x86, can be
worse for others. On x86 we:

 - iowait_start(): was one atomic_inc(), is now still one atomic op --
   raw_spin_lock().

 - iowait_stop(): was one atomic_dec(), is now still one atomic op --
   raw_spin_lock().

The only case we add lots of pain is the remote iowait to 0 case, where
we call ktime_get(). Which gets us to different clocks, what different
clocks?

Also; there's an argument to be made about correctness over performance;
but I feel its a somewhat weak argument since the entire per-cpu iowait
number is still complete bullshit :-)

>   These codes are based on following patch on top of v3.16-rc2:
>     [PATCH] nohz: make updating sleep stats local, add seqcount
> 
>   I'd like to ask you:
> 
>     - Do you think if I continue this direction these blueprints
>       would be acceptable change?

Yeah, so this solves the 'simple' problem of making the iowait
accounting nohz invariant, which is 'good'. It doesn't address the
bigger issue of what it all means. But I suppose we can start here.

>     - Or shall we kill iowait completely?

I'm all in favour of less accounting :-) It might upset some people
though, but you have my blessing if you can get it done.

>     - Are there any good workaround or band-aid for stable kernels?

I suppose this is still backportable to any -stable that is still
maintained ;-) Then again, this has been broken for bloody ever, so I
don't suppose its really that urgent.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]