huang ying writes:
> On Sat, Jan 30, 2016 at 9:18 AM, Ding Tianhong
> wrote:
>> On 2016/1/29 17:53, Peter Zijlstra wrote:
>>> On Sun, Jan 24, 2016 at 04:03:50PM +0800, Ding Tianhong wrote:
>>>
looks good to me, I will try this solution and report the result, thanks
everyone.
>>>
>>>
On Sat, Jan 30, 2016 at 9:18 AM, Ding Tianhong wrote:
> On 2016/1/29 17:53, Peter Zijlstra wrote:
>> On Sun, Jan 24, 2016 at 04:03:50PM +0800, Ding Tianhong wrote:
>>
>>> looks good to me, I will try this solution and report the result, thanks
>>> everyone.
>>
>> Did you get a change to run with
On 2016/1/29 17:53, Peter Zijlstra wrote:
> On Sun, Jan 24, 2016 at 04:03:50PM +0800, Ding Tianhong wrote:
>
>> looks good to me, I will try this solution and report the result, thanks
>> everyone.
>
> Did you get a change to run with this?
>
> .
>
I backport this patch to 3.10 lts kernel, an
On Sun, Jan 24, 2016 at 04:03:50PM +0800, Ding Tianhong wrote:
> looks good to me, I will try this solution and report the result, thanks
> everyone.
Did you get a change to run with this?
On 2016/1/22 21:59, Waiman Long wrote:
> On 01/22/2016 06:06 AM, Peter Zijlstra wrote:
>> On Fri, Jan 22, 2016 at 11:56:52AM +0100, Peter Zijlstra wrote:
>>> On Fri, Jan 22, 2016 at 11:53:12AM +0100, Peter Zijlstra wrote:
>>>
There might be other details, but this is the one that stood out.
>>
On Fri, 22 Jan 2016, Waiman Long wrote:
The patch that I sent out is just a proof of concept to make sure
that it can fix that particular case. I do plan to refactor it if I
decide to go ahead with an official one. Unlike the OSQ, there can be
no more than one waiter spinner as the wakeup functi
On 01/22/2016 06:06 AM, Peter Zijlstra wrote:
On Fri, Jan 22, 2016 at 11:56:52AM +0100, Peter Zijlstra wrote:
On Fri, Jan 22, 2016 at 11:53:12AM +0100, Peter Zijlstra wrote:
There might be other details, but this is the one that stood out.
I think this also does the wrong thing for use_ww_ctx
On 01/22/2016 03:54 AM, Peter Zijlstra wrote:
On Thu, Jan 21, 2016 at 06:02:34PM -0500, Waiman Long wrote:
This patch attempts to fix this live-lock condition by enabling the
a woken task in the wait list to enter optimistic spinning loop itself
with precedence over the ones in the OSQ. This sho
On 01/22/2016 01:09 AM, Davidlohr Bueso wrote:
On Thu, 21 Jan 2016, Waiman Long wrote:
On 01/21/2016 04:29 AM, Ding Tianhong wrote:
I got the vmcore and found that the ifconfig is already in the
wait_list of the
rtnl_lock for 120 second, but my process could get and release the
rtnl_lock
no
On Fri, Jan 22, 2016 at 11:56:52AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 22, 2016 at 11:53:12AM +0100, Peter Zijlstra wrote:
>
> > There might be other details, but this is the one that stood out.
>
> I think this also does the wrong thing for use_ww_ctx.
Something like so?
---
kernel/lo
On Fri, Jan 22, 2016 at 11:53:12AM +0100, Peter Zijlstra wrote:
> There might be other details, but this is the one that stood out.
I think this also does the wrong thing for use_ww_ctx.
On Fri, Jan 22, 2016 at 02:20:19AM -0800, Jason Low wrote:
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -543,6 +543,8 @@ __mutex_lock_common(struct mutex *lock, long state,
> unsigned int subclass,
> lock_contended(&lock->dep_map, ip);
>
> for (;;) {
> +
On Fri, 2016-01-22 at 09:54 +0100, Peter Zijlstra wrote:
> On Thu, Jan 21, 2016 at 06:02:34PM -0500, Waiman Long wrote:
> > This patch attempts to fix this live-lock condition by enabling the
> > a woken task in the wait list to enter optimistic spinning loop itself
> > with precedence over the one
On Thu, Jan 21, 2016 at 06:02:34PM -0500, Waiman Long wrote:
> This patch attempts to fix this live-lock condition by enabling the
> a woken task in the wait list to enter optimistic spinning loop itself
> with precedence over the ones in the OSQ. This should prevent the
> live-lock
> condition fro
On Thu, 21 Jan 2016, Waiman Long wrote:
On 01/21/2016 04:29 AM, Ding Tianhong wrote:
I got the vmcore and found that the ifconfig is already in the wait_list of the
rtnl_lock for 120 second, but my process could get and release the rtnl_lock
normally several times in one second, so it means t
On Thu, Jan 21, 2016 at 06:48:54PM -0800, Davidlohr Bueso wrote:
> On Thu, 21 Jan 2016, Paul E. McKenney wrote:
>
> >I did some testing, which exposed it to the 0day test robot, which
> >did note some performance differences. I was hoping that it would
> >clear up some instability from other patc
On Thu, 21 Jan 2016, Paul E. McKenney wrote:
I did some testing, which exposed it to the 0day test robot, which
did note some performance differences. I was hoping that it would
clear up some instability from other patches, but no such luck. ;-)
Oh, that explains why we got a performance reg
On Thu, Jan 21, 2016 at 01:23:09PM -0800, Tim Chen wrote:
> On Thu, 2016-01-21 at 17:29 +0800, Ding Tianhong wrote:
>
> >
> > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> > index 0551c21..596b341 100644
> > --- a/kernel/locking/mutex.c
> > +++ b/kernel/locking/mutex.c
> > @@ -25
On 01/21/2016 04:29 AM, Ding Tianhong wrote:
I build a script to create several process for ioctl loop calling,
the ioctl will calling the kernel function just like:
xx_ioctl {
...
rtnl_lock();
function();
rtnl_unlock();
...
}
The function may sleep several ms, but will not halt, at the same time
On Thu, 2016-01-21 at 17:29 +0800, Ding Tianhong wrote:
>
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index 0551c21..596b341 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -256,7 +256,7 @@ static inline int mutex_can_spin_on_owner(struct mutex
> *l
I build a script to create several process for ioctl loop calling,
the ioctl will calling the kernel function just like:
xx_ioctl {
...
rtnl_lock();
function();
rtnl_unlock();
...
}
The function may sleep several ms, but will not halt, at the same time
another user service may calling ifconfig to c
On 2016/1/21 15:29, Ingo Molnar wrote:
>
> Cc:-ed other gents who touched the mutex code recently. Mail quoted below.
>
Ok, thanks.
Ding
> Thanks,
>
> Ingo
>
> * Ding Tianhong wrote:
>
>> I build a script to create several process for ioctl loop calling,
>> the ioctl will calling the
Cc:-ed other gents who touched the mutex code recently. Mail quoted below.
Thanks,
Ingo
* Ding Tianhong wrote:
> I build a script to create several process for ioctl loop calling,
> the ioctl will calling the kernel function just like:
> xx_ioctl {
> ...
> rtnl_lock();
> function();
>
I build a script to create several process for ioctl loop calling,
the ioctl will calling the kernel function just like:
xx_ioctl {
...
rtnl_lock();
function();
rtnl_unlock();
...
}
The function may sleep several ms, but will not halt, at the same time
another user service may calling ifconfig to c
24 matches
Mail list logo
