On 11/01/2015 05:32 AM, Manfred Spraul wrote:
> Hi Sebastian,
Hi Manfred,
> with regards to functional tests:
> fakeroot is a heavy system V user (at least if it is configured for sysv).
> "make -j" under fakeroot was a useful stresstest
I don't see the msgsnd/msgrcv syscalls here. I do see othe
On 10/31/2015 08:06 PM, Davidlohr Bueso wrote:
> On Sat, 31 Oct 2015, Bueso wrote:
>
>> Yes, and this confirms that we still rely on the implicit barrier
>> from the cmpxchg as tglx mentioned. As such, we also need to keep
>> the pairing when reading 'r_msg' in do_msgrcv(), instead of dropping
>>
On 10/31/2015 07:54 PM, Davidlohr Bueso wrote:
>> However, a wake_q keeps a reference to a task, so exiting is
>> not a danger. As long as wake_q_add precedes setting r_msg,
>> all is well.
>
> Yes, and this confirms that we still rely on the implicit barrier
> from the cmpxchg as tglx mentioned.
On 10/30/2015 11:30 PM, George Spelvin wrote:
> One very minor kibitz: would you mind using "..." for ellipsis in the
> comments rather than U+2026?
mkay
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Hi Sebastian,
On 10/30/2015 12:26 PM, Sebastian Andrzej Siewior wrote:
This patch moves the wakeup_process() invocation so it is not done under
the perm->lock by making use of a lockless wake_q. With this change, the
waiter is woken up once the message has been assigned and it does not
need to l
On Sat, 31 Oct 2015, Bueso wrote:
Yes, and this confirms that we still rely on the implicit barrier
from the cmpxchg as tglx mentioned. As such, we also need to keep
the pairing when reading 'r_msg' in do_msgrcv(), instead of dropping
the comments.
Hmm having r_msg as volatile seems even less
On Sat, 31 Oct 2015, George Spelvin wrote:
Don't we need to keep that NULL init? I might be missing something.
I wondered the same thing, but on reading it, the cleanup is that he's
gotten rid of the need for the entire thing. Previously, there was a
mechanism for detecting "wakeup not quite
On Sat, 31 Oct 2015, George Spelvin wrote:
> > Don't we need to keep that NULL init? I might be missing something.
>
> I wondered the same thing, but on reading it, the cleanup is that he's
> gotten rid of the need for the entire thing. Previously, there was a
> mechanism for detecting "wakeup no
> Don't we need to keep that NULL init? I might be missing something.
I wondered the same thing, but on reading it, the cleanup is that he's
gotten rid of the need for the entire thing. Previously, there was a
mechanism for detecting "wakeup not quite finished" that used a NULL
value, but it's no
On Fri, 30 Oct 2015, Sebastian Andrzej Siewior wrote:
> This was just compile tested. It would be nice if somone with real
> workload could test it. Otherwise I could hack something myself and check
> if it still works.
ltp and glibc should have tests at least at the functional level
> -static v
I haven't got a test case, but that definitley looks like a great
cleanup!
One very minor kibitz: would you mind using "..." for ellipsis in the
comments rather than U+2026?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
This patch moves the wakeup_process() invocation so it is not done under
the perm->lock by making use of a lockless wake_q. With this change, the
waiter is woken up once the message has been assigned and it does not
need to loop on SMP if the message points to NULL. In the signal case we
still need
12 matches
Mail list logo
