linux-kernel - Re: 2048 CPUs [was: Re: New filesystem for Linux]

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: <Pine.LNX.4.64.0611081921170.5694@artax.karlin.mff.cuni.cz>
Date:	Wed, 8 Nov 2006 19:26:26 +0100 (CET)
From:	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>
To:	Pavel Machek <pavel@....cz>
Cc:	Albert Cahalan <acahalan@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: 2048 CPUs [was: Re: New filesystem for Linux]

Hi!

>>> Lets say time-spent-outside-spinlock == time-spent-in-spinlock and
>>> number-of-cpus == 2.
>>>
>>> 1 < 2 , so it should livelock according to you...
>>
>> There is off-by-one bug in the condition. It should be:
>> (time_spent_in_spinlock + time_spent_outside_spinlock) /
>> time_spent_in_spinlock < number_of_cpus
>>
>> ... or if you divide it by time_spent_in_spinlock:
>> time_spent_outside_spinlock / time_spent_in_spinlock + 1 < number_of_cpus
>>
>>> ...but afaict this should work okay. Even if spinlocks are very
>>> unfair, as long as time-outside and time-inside comes in big chunks,
>>> it should work.
>>>
>>> If you are unlucky, one cpu may stall for a while, but... I see no
>>> livelock.
>>
>> If some rogue threads (and it may not even be intetional) call the same
>> syscall stressing the one spinlock all the time, other syscalls needing
>> the same spinlock may stall.
>
> Fortunately, they'll unstall with probability of 1... so no, I do not
> think this is real problem.

You can't tell that CPUs behave exactly probabilistically --- it may 
happen that one gets out of the wait loop always too late.

SMP buses have complex protocols to prevent starvation in case all CPUs 
are writing to the same cache line and similar --- however it is unusable 
againt spinlock starvation.

> If someone takes semaphore in syscall (we do), same problem may
> happen, right...? Without need for 2048 cpus. Maybe semaphores/mutexes
> are fair (or mostly fair) these days, but rwlocks may not be or
> something.

Scheduler increases priority of sleeping process, so starving process 
should be waken up first. But if there are so many processes, that process 
that passed the semaphore, sleeps and tries to take the semaphore has 
already increased priority to the level of process that waited on the 
semaphor, livelock can happen too.

Mikulas

> 									Pavel
>
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
-
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/