On 03/27/2013 04:42 AM, Peter Zijlstra wrote:
On Tue, 2013-03-26 at 11:19 -0400, Rik van Riel wrote:
Maybe something like:
void sma_lock(struct sem_array *sma) /* global */
{
int i;
sma->global_locked = 1;
smp_wmb(); /* can we merge with the LOCK ? */
spin_lock(&sma
On Wed, 2013-03-27 at 04:22 -0700, Michel Lespinasse wrote:
> >> Not without breaking your scheme above :)
> >
> > How would making sma->global_lock a mutex wreck anything?
>
> I don't remember the details (rik probably will), but rcu is also
> already involved, so there is a non trivial chance th
On Wed, Mar 27, 2013 at 1:42 AM, Peter Zijlstra wrote:
> On Tue, 2013-03-26 at 11:19 -0400, Rik van Riel wrote:
>> > Maybe something like:
>> >
>> > void sma_lock(struct sem_array *sma) /* global */
>> > {
>> > int i;
>> >
>> > sma->global_locked = 1;
>> > smp_wmb(); /* can we me
On Tue, 2013-03-26 at 11:19 -0400, Rik van Riel wrote:
> > Maybe something like:
> >
> > void sma_lock(struct sem_array *sma) /* global */
> > {
> > int i;
> >
> > sma->global_locked = 1;
> > smp_wmb(); /* can we merge with the LOCK ? */
> > spin_lock(&sma->global_lock);
> >
On Tue, 2013-03-26 at 11:19 -0400, Rik van Riel wrote:
> That makes me wonder, how did mm_take_all_locks used to work before
> we turned the anon_vma lock into a mutex?
>
> The code used to use spin_lock_nest_lock, but still has the potential
> to overflow the preempt counter. How did that ever wo
On 03/26/2013 10:27 AM, Peter Zijlstra wrote:
On Tue, 2013-03-26 at 06:40 -0700, Michel Lespinasse wrote:
sem_nsems is user provided as the array size in some semget system
call. It's the size of an ipc semaphore array.
So we're basically adding a random (big) number to preempt_count
(obvious
On Tue, 2013-03-26 at 06:40 -0700, Michel Lespinasse wrote:
> sem_nsems is user provided as the array size in some semget system
> call. It's the size of an ipc semaphore array.
So we're basically adding a random (big) number to preempt_count
(obviously while preemption is disabled), seems rather
On 03/26/2013 09:19 AM, Peter Zijlstra wrote:
On Mon, 2013-03-25 at 14:42 -0700, Michel Lespinasse wrote:
depth nesting here...
Adding Peter & Ingo for advice about how to proceed
+++ b/ipc/sem.c
@@ -357,7 +357,7 @@ static inline int sem_lock(struct sem_array
*sma, struct sembuf *sops,
On Tue, Mar 26, 2013 at 6:19 AM, Peter Zijlstra wrote:
> On Mon, 2013-03-25 at 14:42 -0700, Michel Lespinasse wrote:
>> depth nesting here...
>> Adding Peter & Ingo for advice about how to proceed
>
>> > +++ b/ipc/sem.c
>> > @@ -357,7 +357,7 @@ static inline int sem_lock(struct sem_array
>> *sma,
On Mon, 2013-03-25 at 14:42 -0700, Michel Lespinasse wrote:
> depth nesting here...
> Adding Peter & Ingo for advice about how to proceed
> > +++ b/ipc/sem.c
> > @@ -357,7 +357,7 @@ static inline int sem_lock(struct sem_array
> *sma, struct sembuf *sops,
> > spin_lock(&sma->sem_per
On 03/25/2013 05:51 PM, Michel Lespinasse wrote:
> On Mon, Mar 25, 2013 at 2:42 PM, Michel Lespinasse wrote:
>> I'll be surprised if it does, because we don't actually have single
>> depth nesting here...
>> Adding Peter & Ingo for advice about how to proceed
>> (the one solution I know would invo
On 03/25/2013 05:42 PM, Michel Lespinasse wrote:
> On Mon, Mar 25, 2013 at 1:38 PM, Rik van Riel wrote:
>> > On Mon, 25 Mar 2013 16:21:22 -0400
>> > Sasha Levin wrote:
>> >
>>> >> On 03/20/2013 03:55 PM, Rik van Riel wrote:
>> > Include lkml in the CC: this time... *sigh*
>> > ---8<---
On Mon, Mar 25, 2013 at 2:42 PM, Michel Lespinasse wrote:
> I'll be surprised if it does, because we don't actually have single
> depth nesting here...
> Adding Peter & Ingo for advice about how to proceed
> (the one solution I know would involve using arch_spin_lock() directly
> to bypass the loc
On Mon, Mar 25, 2013 at 1:38 PM, Rik van Riel wrote:
> On Mon, 25 Mar 2013 16:21:22 -0400
> Sasha Levin wrote:
>
>> On 03/20/2013 03:55 PM, Rik van Riel wrote:
>> > Include lkml in the CC: this time... *sigh*
>> > ---8<---
>> >
>> > This series makes the sysv semaphore code more scalable,
>> > by
14 matches
Mail list logo
