Re: [Discuss][i386] Platform SMIs and their interferance with tsc based delay calibration

From: Andrew Morton (akpm_at_osdl.org)
Date: 01/29/05

  • Next message: Roland Dreier: "Re: compat ioctl for submiting URB"
    Date:	Fri, 28 Jan 2005 21:17:07 -0800
    To: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
    
    

    Please don't send emails which contain 500-column lines?

    Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> wrote:
    >
    > Current tsc based delay_calibration can result in significant errors in
    > loops_per_jiffy count when the platform events like SMIs (System Management
    > Interrupts that are non-maskable) are present.

    This seems like an unsolveable problem.

    > Solution:
    > The patch below makes the calibration routine aware of asynchronous events
    > like SMIs. We increase the delay calibration time and also identify any
    > significant errors (greater than 12.5%) in the calibration and notify it
    > to user. Like to know your comments on this.

    I find calibrate_delay_tsc() quite confusing. Are you sure that the
    variable names are correct?

     + tsc_rate_max = (post_end - pre_start) / DELAY_CALIBRATION_TICKS;
     + tsc_rate_min = (pre_end - post_start) / DELAY_CALIBRATION_TICKS;

    that looks strange. I'm sure it all makes sense if one understands the
    algorithm, but it shouldn't be this hard. Please reissue the patch with
    adequate comments which describe what the code is doing.

    Shouldn't calibrate_delay_tsc() be __devinit? (That may generate warnings
    from reference_discarded.pl, but they're false positives)

    From a maintainability POV it's not good that x86 is no longer using the
    generic calibrate_delay() code. Can you rework the code so that all
    architectures must implement arch_calibrate_delay(), then provide stubs for
    all except x86? After all, other architectures/platforms may have the same
    problem.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Roland Dreier: "Re: compat ioctl for submiting URB"

    Relevant Pages

    • Re: mmap + dma_alloc_coherent
      ... but it never got propagated to the other architectures. ... (x86 not marking RAM pages reserved would be one I ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: aio stress panic on 2.6.11-mm1
      ... >> (across different architectures) ... > on x86 it makes a difference of maybe a few cycles. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: aio stress panic on 2.6.11-mm1
      ... > (across different architectures) ... on x86 it makes a difference of maybe a few cycles. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [rfc] lockless get_user_pages for dio (and more)
      ... enough to implement it on any other architectures, ... This allows (at least on x86), an optimistic lockless pagetable walk, ... on the pages (a la lockless pagecache) to achieve a lockless fast_gup. ... struct iovec entry; ...
      (Linux-Kernel)
    • Re: [PATCH] Remove some divide instructions
      ... >other architectures may want to do other things, ... due to the assignment to __base, the shift / mask optimization does not ... optimizations do not propagate through the assignment. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)