ARCH_FREE_PTE_NR 5350

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux