On Fri, 2005-02-25 at 05:58 +, Hugh Dickins wrote:
> On Thu, 24 Feb 2005, Lee Revell wrote:
> > On Thu, 2005-02-24 at 08:26 +, Hugh Dickins wrote:
> > >
> > > If we'd got to it earlier, yes. But 2.6.11 looks to be just a day or
> > > two away, and we've no idea why zap_pte_range or clear_
On Thu, 24 Feb 2005, Lee Revell wrote:
> On Thu, 2005-02-24 at 08:26 +, Hugh Dickins wrote:
> >
> > If we'd got to it earlier, yes. But 2.6.11 looks to be just a day or
> > two away, and we've no idea why zap_pte_range or clear_page_range
> > would have reverted. Nor have we heard from Ingo
On Thu, 2005-02-24 at 08:26 +, Hugh Dickins wrote:
> On Thu, 24 Feb 2005, Lee Revell wrote:
> > On Thu, 2005-02-24 at 04:56 +, Hugh Dickins wrote:
> > >
> > > In other mail, you do expect people still to be using Ingo's patches,
> > > so probably this patch should stick there (and in -mm)
On Thu, 24 Feb 2005, Lee Revell wrote:
> On Thu, 2005-02-24 at 04:56 +, Hugh Dickins wrote:
> >
> > In other mail, you do expect people still to be using Ingo's patches,
> > so probably this patch should stick there (and in -mm) for now.
>
> Well all of these were fixed in the past so it may
On Thu, 2005-02-24 at 04:56 +, Hugh Dickins wrote:
> On Wed, 23 Feb 2005, Lee Revell wrote:
> > On Wed, 2005-02-23 at 20:53 +, Hugh Dickins wrote:
> > > On Wed, 23 Feb 2005, Hugh Dickins wrote:
> > > > Please replace by new patch below, which I'm now running through
> > > > lmbench.
> > >
On Wed, 23 Feb 2005, Lee Revell wrote:
> On Wed, 2005-02-23 at 20:53 +, Hugh Dickins wrote:
> > On Wed, 23 Feb 2005, Hugh Dickins wrote:
> > > Please replace by new patch below, which I'm now running through lmbench.
> >
> > That second patch seems fine, and I see no lmbench regression from it
On Thu, 2005-02-24 at 13:41 +1100, Nick Piggin wrote:
> Lee Revell wrote:
> >
> > Agreed, it would be much better to optimize this away than just add a
> > scheduling point. It seems like we could do this lazily.
> >
>
> Oh? What do you mean by lazy? IMO it is sort of implemented lazily now.
>
Lee Revell wrote:
On Thu, 2005-02-24 at 12:29 +1100, Nick Piggin wrote:
Lee Revell wrote:
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.
Well it should be pretty trivial to
On Thu, 2005-02-24 at 12:29 +1100, Nick Piggin wrote:
> Lee Revell wrote:
> >
> > 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.
> >
> Well it should be pretty tri
Lee Revell wrote:
On Thu, 2005-02-24 at 10:27 +1100, Nick Piggin wrote:
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 15
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 th
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 beco
On Wed, 2005-02-23 at 21:03 +, 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.
Heh, sorry, that one was a dupe... I
On Wed, 2005-02-23 at 20:53 +, Hugh Dickins wrote:
> On Wed, 23 Feb 2005, Hugh Dickins wrote:
> > Please replace by new patch below, which I'm now running through lmbench.
>
> That second patch seems fine, and I see no lmbench regression from it.
Should go into 2.6.11, right?
Lee
-
To unsub
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
On Wed, 23 Feb 2005, Hugh Dickins wrote:
> Please replace by new patch below, which I'm now running through lmbench.
That second patch seems fine, and I see no lmbench regression from it.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
On Wed, 2005-02-23 at 20:06 +, Hugh Dickins wrote:
> >
> > Thanks, your patch fixes the copy_pte_range latency.
>
> Great, if the previous patch fixed that latency then this new one
> will too, no need to report on that; but please get rid of the old
> patch before it leaks too many of your p
On Wed, 2005-02-23 at 20:06 +, Hugh Dickins wrote:
> On Wed, 23 Feb 2005, Lee Revell wrote:
> > On Wed, 2005-02-23 at 19:16 +, Hugh Dickins wrote:
> > >
> > > I'm just about to test this patch below: please give it a try: thanks...
>
> I'm very sorry, there's two things wrong with that ve
On Wed, 23 Feb 2005, Lee Revell wrote:
> On Wed, 2005-02-23 at 19:16 +, Hugh Dickins wrote:
> >
> > I'm just about to test this patch below: please give it a try: thanks...
I'm very sorry, there's two things wrong with that version: _must_
increment addr before breaking out, and better to che
On Wed, 2005-02-23 at 19:16 +, Hugh Dickins wrote:
> On Wed, 23 Feb 2005, Lee Revell wrote:
> >
> > Did something change recently in the VM that made copy_pte_range and
> > clear_page_range a lot more expensive? I noticed a reference in the
> > "Page Table Iterators" thread to excessive overh
On Wed, 23 Feb 2005, Lee Revell wrote:
>
> Did something change recently in the VM that made copy_pte_range and
> clear_page_range a lot more expensive? I noticed a reference in the
> "Page Table Iterators" thread to excessive overhead introduced by
> aggressive page freeing. That sure looks lik
Ingo,
Did something change recently in the VM that made copy_pte_range and
clear_page_range a lot more expensive? I noticed a reference in the
"Page Table Iterators" thread to excessive overhead introduced by
aggressive page freeing. That sure looks like what is going on in
trace2. trace1 and t
22 matches
Mail list logo
