From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <93cb4c7c46cd98af895c531e743e7bb3@quanstro.net> From: erik quanstrom Date: Thu, 3 Sep 2009 21:52:07 -0400 To: drivers@0xabadba.be, 9fans@9fans.net In-Reply-To: <182803949-1252028217-cardhu_decombobulator_blackberry.rim.net-863554438-@bda790.bisx.prod.on.blackberry> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] "Blocks" in C Topicbox-Message-UUID: 6391caa8-ead5-11e9-9d60-3106f5b1d025 On Thu Sep 3 21:38:30 EDT 2009, drivers@0xabadba.be wrote: > To ensure only one thread in the kernel at a time? yes. http://en.wikipedia.org/wiki/Giant_lock it allows only one kernel thread to run at a time. the pool lock allows as many threads to run as one would like, but they can't allocate concurrently since blocks and kernel buffers are allocated through the pool library. this effectively ties kernel procs doing io together by their shoelaces. it's a big reason that a number of ethernet drivers have private frame pools. cutting the lock (any lock) out of the mix when shuffling very small blocks around the kernel was worth double the blocks/s in some tests i did. sorry to be vague. i don't have a good writeup. - erik