Re: More latency regressions with 2.6.11-rc4-RT-V0.7.39-02

[Lee Revell <rlrevell@joe-job.com>]

On Thu, 2005-02-24 at 10:27 +1100, Nick Piggin wrote: 
> Hugh Dickins wrote:
> > On Wed, 23 Feb 2005, Lee Revell wrote:
> > 
> >>>>Thanks, your patch fixes the copy_pte_range latency.
> >>
> >>clear_page_range is also problematic.
> > 
> > 
> > Yes, I saw that from your other traces too.  I know there are plans
> > to improve clear_page_range during 2.6.12, but I didn't realize that
> > it had become very much worse than its antecedent clear_page_tables,
> > and I don't see missing latency fixes for that.  Nick's the expert.
> > 
> 
> I wouldn't have thought it should have become worse, latency
> wise. What is actually happening is that the lower level freeing
> functions are being called more often. But this should result in
> the work being spread out more, if anything. Rather than in the
> old system things would tend to be batched up into bigger chunks
> (typically at exit() time).
> 
> If you are using i386 with 2-level page tables (no highmem), then
> the behaviour should be more or less identical. Odd.

IIRC last time I really tested this a few months ago, the worst case
latency on that machine was about 150us.  Currently its 422us from the
same clear_page_range code path.

On my Athlon XP the clear_page_range latency is not showing up at all,
and the worst delay so far is only 35us, most of which is the timer
interrupt IOW that machine is showing the best achievable latency (with
PREEMPT_DESKTOP).  The machine seeing 422 us latencies in
clear_page_range is a 600Mhz C3, which is known to be a FSB limited
architecture.

Lee