From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4BAB7B7A.60904@maht0x0r.net>
Date: Thu, 25 Mar 2010 15:04:26 +0000
From: maht <maht-9fans@maht0x0r.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: 9fans@9fans.net
References: <09878a44d12791405e8b8b2bebb140f4@ladd.quanstro.net>
In-Reply-To: <09878a44d12791405e8b8b2bebb140f4@ladd.quanstro.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] quote o' the day
Topicbox-Message-UUID: f143f7cc-ead5-11e9-9d60-3106f5b1d025

On 25/03/2010 14:08, erik quanstrom wrote:
> http://lwn.net/Articles/378219/
> 	"[...] anything which combines tricky locking
> 	and 30-line preprocessor macros is going to raise eyebrows.
> 	But the core concept here is simple: [...]
>
> oh, really?
>
> - erik
>
>

Trying to acquire one lock per CPU will work just dandy.

 > One such case - the target for this new lock - is vfsmount_lock,
which is required (for read access) in pathname lookup operations.
Lookups are frequent events, and are clearly performance-critical. On
the other hand, write access is only needed when filesystems are being
mounted or unmounted - a much rarer occurrence. So a brlock is a good
fit here, and one small piece (out of many) of the VFS scalability
puzzle has been put into place.


bye bye private Linux namespaces, it wasn't even nice knowing you