Hi,
Looking at the tlb_flush code path and its co-relation with
ARCH_FREE_PTE_NR, on x86-64 architecture. I think we still don't use
the ARCH_FREE_PTE_NR of 5350 as the caching value for the mmu_gathers
structure, instead fallback to using 506 due to some typo errors in
the code.
Found this link in the archives.
http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/1821.html
I don't think anything has been done on this yet (looked at 2.6.23).
Do let me know if its only a typo that needs a fix, or we are still
waiting for some other other changes to come into effect.
Thanks,
Alok.
On Monday 15 October 2007 16:54, Alok kataria wrote:
> Hi,
>
> Looking at the tlb_flush code path and its co-relation with
> ARCH_FREE_PTE_NR, on x86-64 architecture. I think we still don't use
> the ARCH_FREE_PTE_NR of 5350 as the caching value for the mmu_gathers
> structure, instead fallback to using 506 due to some typo errors in
> the code.
>
> Found this link in the archives.
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/1821.html
>
> I don't think anything has been done on this yet (looked at 2.6.23).
> Do let me know if its only a typo that needs a fix, or we are still
> waiting for some other other changes to come into effect.
ARCH_FREE_PTE_NR should probably just get ripped out completely at
this point. Something similar (but working) could be added back if
anybody actually had a workload where it helps to increase the mmu
batch size.
On Mon, 15 Oct 2007, Nick Piggin wrote:
> On Monday 15 October 2007 16:54, Alok kataria wrote:
> >
> > Looking at the tlb_flush code path and its co-relation with
> > ARCH_FREE_PTE_NR, on x86-64 architecture. I think we still don't use
> > the ARCH_FREE_PTE_NR of 5350 as the caching value for the mmu_gathers
> > structure, instead fallback to using 506 due to some typo errors in
> > the code.
> >
> > Found this link in the archives.
> >
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/1821.html
> >
> > I don't think anything has been done on this yet (looked at 2.6.23).
> > Do let me know if its only a typo that needs a fix, or we are still
> > waiting for some other other changes to come into effect.
>
> ARCH_FREE_PTE_NR should probably just get ripped out completely at
> this point. Something similar (but working) could be added back if
> anybody actually had a workload where it helps to increase the mmu
> batch size.
Agreed. No hurry, but thanks to Alok for reminding us.
CC'ing Ben since he's the one most active in mmu_gathering these days.
CC'ing Thomas lest he's puzzling over it in the x86 merge.
Hugh
> Agreed. No hurry, but thanks to Alok for reminding us.
> CC'ing Ben since he's the one most active in mmu_gathering these days.
> CC'ing Thomas lest he's puzzling over it in the x86 merge.
Hrm... yes, that stuff sucks. I've had my work on mmu gather on hold
since KS due to other priorities showing up, but I'll get back to it
soon and put that on the todo list.
The main pain here is the immap_lock. I have various plans to get rid of
preemption blocking in the main mmu gather (the stuff we discussed
already basically), but the immap_lock must stay, so we need to keep
something akin to immap_lock.
With the new approach, the disconnect between ZAP_BLOCK_SIZE and
whatever we use to represent the size of a batch might still be relevant
for the cases where we aren't holding that lock.
I'll get back to that stuff soon and we can then discuss the details.
Ben.