Re: [RFC 4/4]x86: avoid tlbstate lock if no enough cpus

[Eric Dumazet]

Le mercredi 03 novembre 2010 Ã 14:44 +0800, Shaohua Li a Ãcrit :
> This one isn't related to previous patch. If online cpus are below
> NUM_INVALIDATE_TLB_VECTORS, we don't need the lock. The comments
> in the code declares we don't need the check, but a hot lock still
> needs an atomic operation and expensive, so add the check here.
> 
> Signed-off-by: Shaohua Li <shaohua.li@xxxxxxxxx>
> ---
>  arch/x86/mm/tlb.c |   14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> Index: linux/arch/x86/mm/tlb.c
> ===================================================================
> --- linux.orig/arch/x86/mm/tlb.c	2010-11-02 10:31:51.000000000 +0800
> +++ linux/arch/x86/mm/tlb.c	2010-11-02 14:53:27.000000000 +0800
> @@ -174,17 +174,16 @@ static void flush_tlb_others_ipi(const s
>  {
>  	unsigned int sender;
>  	union smp_flush_state *f;
> +	bool do_lock = false;
>  
>  	/* Caller has disabled preemption */
>  	sender = this_cpu_read(tlb_vector_offset);
>  	f = &flush_state[sender];
>  
> -	/*
> -	 * Could avoid this lock when
> -	 * num_online_cpus() <= NUM_INVALIDATE_TLB_VECTORS, but it is
> -	 * probably not worth checking this for a cache-hot lock.
> -	 */
> -	raw_spin_lock(&f->tlbstate_lock);
> +	if (num_online_cpus() > NUM_INVALIDATE_TLB_VECTORS) {

Ouch, you remove a comment that pretty well explained the problem.

Last time I checked, num_online_cpus() was pretty expensive on a 4096
cpus machine, since 4096 bits array is 512 bytes long.

Are you sure you didnt want to use nr_cpu_ids here ?

> +		do_lock = true;
> +		raw_spin_lock(&f->tlbstate_lock);
> +	}
>  
>  	f->flush_mm = mm;
>  	f->flush_va = va;
> @@ -202,7 +201,8 @@ static void flush_tlb_others_ipi(const s
>  
>  	f->flush_mm = NULL;
>  	f->flush_va = 0;
> -	raw_spin_unlock(&f->tlbstate_lock);
> +	if (do_lock)
> +		raw_spin_unlock(&f->tlbstate_lock);
>  }
>  
>  void native_flush_tlb_others(const struct cpumask *cpumask,
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/