Message-ID: <414BCB5B.8020507@colorfullife.com>
Date: Sat, 18 Sep 2004 07:44:59 +0200
From: Manfred Spraul <manfred@colorfullife.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Tony Lee <tony.p.lee@gmail.com>
CC: linux-kernel@vger.kernel.org
Subject: Re: [patch] remove the BKL (Big Kernel Lock), this time for real
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1272
Lines: 32

Tony wrote:

>I coded a IPC system before use atomic add + share memory.  
>It works very well (fast) on 4 CPU SMP system, since it doesn't use 
>any locking API at all.    Very good for resource allocation for 
>SMP.     I implemented speciall malloc/free use by ISR, different
>prority process completely without any lock.
>
Without any lock or without any common cacheline that are accessed by 
atomic operations?
I usually consider the costs of
    atomic_inc(&global_atomic_var);
and
    spin_lock(&global_lock);
    global_var++;
    spin_unlock(&global_lock);
as nearly identical (assuming that global_var and global_lock are in the 
same cacheline): one cachline transfer per run. The 5 instructions under 
the spinlock and the theoretical chance that spin_lock() blocks are 
noise compared to the cost of the line transfer.
And that's without thinking about smb_mb__{before,after}_atomic_inc().

Btw, Ingo forgot to mention sequence locks and percpu_counter as two 
high-scalability locking primitives.

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