> The onstack array seems fine to me, even if you do end up deciding on
> an array of one. Is there any evidence that it's a problem getting a
> page for the freeing (other than in circumstances that are already
> badly slowed down)? It's obvious that we need a fallback route,
> but optimizing t
On Sat, 28 Jul 2007, Benjamin Herrenschmidt wrote:
>
> As I'm sweeping through arch code etc... preparing the ground for the
> proper mmu_gather surgery, I've been thinking about the way to deal with
> that per-cpu page list and finally came up with the idea that the best
> we can do is around the
> > So I'll first do patch #1, which will not fix the problem, but will make
> > the fix easier to fit in, in the meantime, please provide feedback of
> > your preferred solution for avoiding the get/put_cpu of the 2 above,
> > unless you find a good 3rd one.
>
> I too would prefer the former sol
On Thu, 2007-07-26 at 18:11 +0100, Hugh Dickins wrote:
> That will often be the case for anonymous pages, but not for pagecache
> pages. I had wondered whether to make exit_mmap unmap the stack first
> (rather than text first as usually happens), but seems rather a hack.
Yup and defeated by HIGHM
On Wed, 25 Jul 2007, Benjamin Herrenschmidt wrote:
>
> In fact, i discussed with peter and I think the best is to only have one
> entry in the stack mmu_gather structure.
Four or eight would be much nicer than one, but you're right there's
a stackdepth worry: good spotting of those unmap_mapping_
On Wed, 2007-07-25 at 12:26 +0200, Andi Kleen wrote:
> > Plan is fixed array or 4 or maybe 8 entries (pointers), that shouldn't
> > be -too- bad. The code path I'm a bit worried about is
>
> Yep.
>
> > unmap_mapping_ranges() which goes into zapping page tables from deep
> > within filesystems.
>
> Plan is fixed array or 4 or maybe 8 entries (pointers), that shouldn't
> be -too- bad. The code path I'm a bit worried about is
Yep.
> unmap_mapping_ranges() which goes into zapping page tables from deep
> within filesystems.
Your aim is to conserve stack space?
The worst case has to work wit
On Wed, 2007-07-25 at 11:46 +0200, Andi Kleen wrote:
> > You could perhaps use C99 variable length arrays to avoid the stack
> > waste when not needed, however Andi once told me that generates rather
> > dubious code.
>
> It generates frame pointers, but that's not that bad. I'm not
> aware of a
> You could perhaps use C99 variable length arrays to avoid the stack
> waste when not needed, however Andi once told me that generates rather
> dubious code.
It generates frame pointers, but that's not that bad. I'm not
aware of any other bad side effects. Ok the compiler will limit
your goto u
On Wed, 2007-07-25 at 07:29 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-07-24 at 14:13 +0200, Andi Kleen wrote:
> > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> >
> > > > What a truly putrid patch. I am suspecting that this was a quick
> > > > get-you-out-of-trouble thing, which t
On Tue, 2007-07-24 at 14:13 +0200, Andi Kleen wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > > What a truly putrid patch. I am suspecting that this was a quick
> > > get-you-out-of-trouble thing, which then got forgotten about.
> > >
> > > We have two months to do the "right f
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> What a truly putrid patch. I am suspecting that this was a quick
> get-you-out-of-trouble thing, which then got forgotten about.
>
> We have two months to do the "right fix". Please?
sure. Just wanted to bring attention to this issue - the regress
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> > What a truly putrid patch. I am suspecting that this was a quick
> > get-you-out-of-trouble thing, which then got forgotten about.
> >
> > We have two months to do the "right fix". Please?
>
> Working on it...
Ideally the patch would DTR
> What a truly putrid patch. I am suspecting that this was a quick
> get-you-out-of-trouble thing, which then got forgotten about.
>
> We have two months to do the "right fix". Please?
Working on it...
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Tue, 2007-07-24 at 10:38 +0200, Ingo Molnar wrote:
> the patch below has been tested in -rt for a long time - lets get it
> upstream please. It fixes some bad latencies on PREEMPT too.
Note that I'm working on the "right way" (reworking mmu gathering)
Patches hopefully this week.
Ben.
>
On Tue, 24 Jul 2007 10:38:55 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> the patch below has been tested in -rt for a long time - lets get it
> upstream please. It fixes some bad latencies on PREEMPT too.
>
> Ingo
>
> --->
> From: Hugh Dickins <[EMAIL PROTECTED]>
the patch below has been tested in -rt for a long time - lets get it
upstream please. It fixes some bad latencies on PREEMPT too.
Ingo
--->
From: Hugh Dickins <[EMAIL PROTECTED]>
Subject: mm: reduce pagetable-freeing latencies
2.6.15-rc1 moved the unlinking of a vma
17 matches
Mail list logo
