linux-kernel - RE: semaphore and mutex in current Linux kernel (3.2.2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <491D6B4EAD0A714894D8AD22F4BDE0439F9560@SCYBEXDAG02.amd.com>
Date:	Mon, 2 Apr 2012 15:28:23 +0000
From:	"Chen, Dennis (SRDC SW)" <Dennis1.Chen@....com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>
Subject: RE: semaphore and mutex in current Linux kernel (3.2.2)

On Sun, Apr 1, 2012 at 8:19 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Chen, Dennis (SRDC SW) <Dennis1.Chen@....com> wrote:
>
>> Documentation/mutex-design.txt:
>>
>> "- 'struct mutex' is smaller on most architectures: E.g. on x86,
>>    'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes.
>>    A smaller structure size means less RAM footprint, and better
>>    CPU-cache utilization."
>> ================================================================
>>
>> Now in my x86-64 32-bit Linux environment, 'struct semaphone'
>> is 16 bytes, 'struct mutex' is 20 bytes. So seems the RAM
>> footprint advantages are not there...
>
> It got larger due to the adaptive spin-mutex performance
> optimization.
>

Thanks Ingo, so part of the document is obsolete and "less RAM footprint" and "tighter code"
is not advantage of mutex anymore, being the disadvantage factor. Spin-mutex performance optimization
is highly expected...   

>> For the performance advantages followed, I don't have the
>> ./test-mutex and maybe the testing environment, so haven't the
>> 1st hand data for this item...
>
> Well, a way to reproduce that would be to find a lock_mutex
> intense workload ('perf top -g', etc.), and then changing back
> the underlying mutex to a semaphore, and measure the performance
> of the two primitives.
>
Why not the 'test-mutex' tool in the document? 
I guess it should be the private tool from you, if you can share it to me then I can help to make
a new round performance check of the two primitives in the latest kernel... make a deal?  
 

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