ARCH_FREE_PTE_NR 5350

ARCH_FREE_PTE_NR 5350

[Hugh Dickins]

Hi Andi,

I'm mightily puzzled by your ARCH_FREE_PTE_NR 5350 TLB flush speedup
in 2.6.14-rc1.

Partly because all the PTE->PTR typos in include/asm-generic/tlb.h

  #ifdef ARCH_FREE_PTR_NR
    #define FREE_PTR_NR   ARCH_FREE_PTR_NR
  #else

make it do nothing at all.

And partly because mm/memory.c unmap_vmas() is still using:

#ifdef CONFIG_PREEMPT
# define ZAP_BLOCK_SIZE	(8 * PAGE_SIZE)
#else
/* No preempt: go for improved straight-line efficiency */
# define ZAP_BLOCK_SIZE	(1024 * PAGE_SIZE)
#endif

which would make most of your increase just a waste of space.

Yes, it's long been wrong for ZAP_BLOCK_SIZE to be disconnected
from FREE_PTE_NR.  And there's a serious conflict here between the low
latency people (who don't like thousands of pages freed with preemption
disabled) and the high throughput people (who don't like the terrible
drop that ZAP_BLOCK_SIZE is imposing).

I do think we need to sort this out, but maybe wait until after I've
done my page_table_lock changes - which do change the picture here
(the lock is taken lower down), but not solve it (per-cpu mmu_gather
still needs preemption disabled).

Hugh

Re: ARCH_FREE_PTE_NR 5350

[Andi Kleen]

On Tuesday 13 September 2005 17:54, Hugh Dickins wrote:

> Partly because all the PTE->PTR typos in include/asm-generic/tlb.h
>
>   #ifdef ARCH_FREE_PTR_NR
>     #define FREE_PTR_NR   ARCH_FREE_PTR_NR
>   #else

Yuck. The initial prototype did something, but a later cleanup broke it :/

> I do think we need to sort this out, but maybe wait until after I've
> done my page_table_lock changes - which do change the picture here
> (the lock is taken lower down), but not solve it (per-cpu mmu_gather
> still needs preemption disabled).

Ok.

-Andi