lkml.org 
[lkml]   [2017]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH v2 7/7] sched/idle: update poll time when wakeup from idle
    From
    Date


    On 2017/8/29 20:46, Peter Zijlstra wrote:
    > On Tue, Aug 29, 2017 at 11:46:41AM +0000, Yang Zhang wrote:
    >> In ttwu_do_wakeup, it will update avg_idle when wakeup from idle. Here
    >> we just reuse this logic to update the poll time. It may be a little
    >> late to update the poll in ttwu_do_wakeup, but the test result shows no
    >> obvious performance gap compare with updating poll in irq handler.
    >>
    >> one problem is that idle_stamp only used when using CFS scheduler. But
    >> it is ok since it is the default policy for scheduler and only consider
    >> it should enough.
    >>
    >> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
    >> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
    > Same broken SoB chain, and not a useful word on why you need to adjust
    > this crap to begin with. What you want that poll duration to be related
    > to is the cost of a VMEXIT/VMENTER cycle, not however long we happened
    > to be idle.
    >
    > So no.

    Peter,

    I think you are right..

    IIUC, the time we happened to be idle may contain a chain of
    VMEXIT/VMENTER cycles,
    which would be mainly (except the last VMEXIT/VMENTER cycles) for just
    idle loops. right?

    as you mentioned, poll duration to be related to is the cost of __a__
    VMEXIT/VMENTER cycle.
    howerver it is very difficult to measure a VMEXIT/VMENTER cycle
    accurately from
    kvm guest, we could find out an approximate one -- dropping the idle
    loops from the
    time we happened to be idle.. make sense?

    Quan

    \
     
     \ /
      Last update: 2017-09-29 12:32    [W:3.681 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site