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]

Date:	Fri, 6 Apr 2012 09:45:50 +0000
From:	"Chen, Dennis (SRDC SW)" <Dennis1.Chen@....com>
To:	Clemens Ladisch <clemens@...isch.de>
CC:	Ingo Molnar <mingo@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: semaphore and mutex in current Linux kernel (3.2.2)

On Thu, Apr 5, 2012 at 10:15 PM, Clemens Ladisch <clemens@...isch.de> wrote:
> Chen, Dennis (SRDC SW) wrote:
>> I know that the rationale of the mutex's optimization is, if the lock owner is
>> running, it's likely to release the lock soon. So make the waiter to spin a
>> short time waiting for the lock to be released is reasonable given the workload
>> of a process switch.
>>
>> But how about if the lock owner running doesn't release the lock soon?
>
> It would not make sense to spin too long, especially if some other
> process wants to run on the same CPU.

Yes, you're right. If the waiter spin too long to wait for the owner to release the 
lock, the system performance will be degraded...

>> int mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
>> {
>>       ...
>>       while (owner_running(lock, owner)) {
>>               if (need_resched())
>>                       break;
>>
>>               arch_mutex_cpu_relax();
>>       }
>>       ...
>> }
>>
>> [experiment]
>>
>> D+ means the App in CPU1 is sleeping in a UNINTERRUPTIBLE state. This is very interesting,
>> How does this happen?
>
> Your experiment shows that there must be some condition that makes the
> code break out of the spin loop ...

I guess this is related with RCU component, but I don't found the right place where the code 
Located yet. So Ingo's comments will be very helpful event a little bit... :-)

--
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/