On Thu, Sep 04, 2014 at 10:22:08AM +0800, Lai Jiangshan wrote:
> > dest_cpu = cpumask_any_and(cpu_active_mask, new_mask);
> > - if (task_on_rq_queued(p)) {
> > + if (task_on_rq_queued(p) || p->state == TASK_WAKING) {
>
> unrelated question: why we have to stop the cpu even the task is
>
On Thu, Sep 04, 2014 at 10:22:08AM +0800, Lai Jiangshan wrote:
dest_cpu = cpumask_any_and(cpu_active_mask, new_mask);
- if (task_on_rq_queued(p)) {
+ if (task_on_rq_queued(p) || p-state == TASK_WAKING) {
unrelated question: why we have to stop the cpu even the task is
not
On 09/03/2014 11:15 PM, Peter Zijlstra wrote:
> On Mon, Sep 01, 2014 at 11:04:23AM +0800, Lai Jiangshan wrote:
>> Hi, Peter
>>
>> Could you make a patch for it, please? Jason J. Herne's test showed we
>> addressed the bug. But the fix is not in kernel yet. Some new highly
>> related reports are
On Mon, Sep 01, 2014 at 11:04:23AM +0800, Lai Jiangshan wrote:
> Hi, Peter
>
> Could you make a patch for it, please? Jason J. Herne's test showed we
> addressed the bug. But the fix is not in kernel yet. Some new highly
> related reports are come up again.
>
> I don't want to argue any more,
On Mon, Sep 01, 2014 at 11:04:23AM +0800, Lai Jiangshan wrote:
Hi, Peter
Could you make a patch for it, please? Jason J. Herne's test showed we
addressed the bug. But the fix is not in kernel yet. Some new highly
related reports are come up again.
I don't want to argue any more, no
On 09/03/2014 11:15 PM, Peter Zijlstra wrote:
On Mon, Sep 01, 2014 at 11:04:23AM +0800, Lai Jiangshan wrote:
Hi, Peter
Could you make a patch for it, please? Jason J. Herne's test showed we
addressed the bug. But the fix is not in kernel yet. Some new highly
related reports are come up
Hi, Peter
Could you make a patch for it, please? Jason J. Herne's test showed we
addressed the bug. But the fix is not in kernel yet. Some new highly
related reports are come up again.
I don't want to argue any more, no matter how the patch will be,
I will accept. And please add the following
Hi, Peter
Could you make a patch for it, please? Jason J. Herne's test showed we
addressed the bug. But the fix is not in kernel yet. Some new highly
related reports are come up again.
I don't want to argue any more, no matter how the patch will be,
I will accept. And please add the following
Hi, Peter
Ping...
thanks,
Lai
On 06/10/2014 09:21 AM, Lai Jiangshan wrote:
> On 06/09/2014 10:01 PM, Jason J. Herne wrote:
>> On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
>>>
>>>
>>> Subject: [PATCH] sched: migrate the waking tasks
>>>
>>> Current code skips to migrate the waking
Hi, Peter
Ping...
thanks,
Lai
On 06/10/2014 09:21 AM, Lai Jiangshan wrote:
On 06/09/2014 10:01 PM, Jason J. Herne wrote:
On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
Subject: [PATCH] sched: migrate the waking tasks
Current code skips to migrate the waking task silently when
On 06/09/2014 10:01 PM, Jason J. Herne wrote:
> On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
>>
>>
>> Subject: [PATCH] sched: migrate the waking tasks
>>
>> Current code skips to migrate the waking task silently when TTWU_QUEUE is
>> enabled.
>>
>> When a task is waking, it is
On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
Subject: [PATCH] sched: migrate the waking tasks
Current code skips to migrate the waking task silently when TTWU_QUEUE is
enabled.
When a task is waking, it is pending on the wake_list of the rq, but
it is not on queue (task->on_rq
On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
Subject: [PATCH] sched: migrate the waking tasks
Current code skips to migrate the waking task silently when TTWU_QUEUE is
enabled.
When a task is waking, it is pending on the wake_list of the rq, but
it is not on queue (task-on_rq ==
On 06/09/2014 10:01 PM, Jason J. Herne wrote:
On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
Subject: [PATCH] sched: migrate the waking tasks
Current code skips to migrate the waking task silently when TTWU_QUEUE is
enabled.
When a task is waking, it is pending on the
On 06/06/2014 09:36 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 06:54:35PM +0800, Lai Jiangshan wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 268a45e..d05a5a1 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1474,20 +1474,24 @@ static int
On 06/06/2014 09:36 PM, Peter Zijlstra wrote:
On Thu, Jun 05, 2014 at 06:54:35PM +0800, Lai Jiangshan wrote:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 268a45e..d05a5a1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1474,20 +1474,24 @@ static int
On Thu, Jun 05, 2014 at 06:54:35PM +0800, Lai Jiangshan wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 268a45e..d05a5a1 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1474,20 +1474,24 @@ static int ttwu_remote(struct task_struct *p, int
> wake_flags)
On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
The patch is not tested by Jason, I don't know whether the patch fix the
problem.
The changlog including the "Reported-by:" and "Tested-by:" need to be updated
after it is proved.
With this patch, my workload ran overnight without hitting the
On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
The patch is not tested by Jason, I don't know whether the patch fix the
problem.
The changlog including the Reported-by: and Tested-by: need to be updated
after it is proved.
With this patch, my workload ran overnight without hitting the warning.
On Thu, Jun 05, 2014 at 06:54:35PM +0800, Lai Jiangshan wrote:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 268a45e..d05a5a1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1474,20 +1474,24 @@ static int ttwu_remote(struct task_struct *p, int
wake_flags)
}
On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
The patch is not tested by Jason, I don't know whether the patch fix the
problem.
The changlog including the "Reported-by:" and "Tested-by:" need to be updated
after it is proved.
I will test this one and get back to you as soon as possible.
--
--
The patch is not tested by Jason, I don't know whether the patch fix the
problem.
The changlog including the "Reported-by:" and "Tested-by:" need to be updated
after it is proved.
Subject: [PATCH] sched: migrate the waking tasks
Current code skips to migrate the waking task
The patch is not tested by Jason, I don't know whether the patch fix the
problem.
The changlog including the Reported-by: and Tested-by: need to be updated
after it is proved.
Subject: [PATCH] sched: migrate the waking tasks
Current code skips to migrate the waking task silently
On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
The patch is not tested by Jason, I don't know whether the patch fix the
problem.
The changlog including the Reported-by: and Tested-by: need to be updated
after it is proved.
I will test this one and get back to you as soon as possible.
--
--
On Wed, Jun 04, 2014 at 04:25:15PM +0800, Lai Jiangshan wrote:
> I think the following code works. (inspirited from the sched_ttwu_pending()
> in migration_call().)
>
> if p->on_rq == 0 && p->state == TASK_WAKING in __migrate_task() after this
> patch,
> it means the cpuallowed is changed
On 06/04/2014 02:49 PM, Peter Zijlstra wrote:
> On Wed, Jun 04, 2014 at 10:27:25AM +0800, Lai Jiangshan wrote:
>>> Hmm, yes I think you're right. A queued wakeup can miss an affinity
>>> change like that.
>>>
>>> Something like the below ought to cure that I suppose..
>>
>> As a non-scheduler
On Wed, Jun 04, 2014 at 10:27:25AM +0800, Lai Jiangshan wrote:
> > Hmm, yes I think you're right. A queued wakeup can miss an affinity
> > change like that.
> >
> > Something like the below ought to cure that I suppose..
>
> As a non-scheduler developer, I can't find anything wrong with the
On Wed, Jun 04, 2014 at 10:28:50AM +0800, Lai Jiangshan wrote:
> On 06/03/2014 07:24 PM, Lai Jiangshan wrote:
> > Hi, Jason
> >
> > Could you test again after the following command has done.
> > (if Peter hasn't asked you test with this command before nor he doesn't
> > stop you now)
> >
> >
On Wed, Jun 04, 2014 at 10:28:50AM +0800, Lai Jiangshan wrote:
On 06/03/2014 07:24 PM, Lai Jiangshan wrote:
Hi, Jason
Could you test again after the following command has done.
(if Peter hasn't asked you test with this command before nor he doesn't
stop you now)
echo
On Wed, Jun 04, 2014 at 10:27:25AM +0800, Lai Jiangshan wrote:
Hmm, yes I think you're right. A queued wakeup can miss an affinity
change like that.
Something like the below ought to cure that I suppose..
As a non-scheduler developer, I can't find anything wrong with the patch
(I
On 06/04/2014 02:49 PM, Peter Zijlstra wrote:
On Wed, Jun 04, 2014 at 10:27:25AM +0800, Lai Jiangshan wrote:
Hmm, yes I think you're right. A queued wakeup can miss an affinity
change like that.
Something like the below ought to cure that I suppose..
As a non-scheduler developer, I can't
On Wed, Jun 04, 2014 at 04:25:15PM +0800, Lai Jiangshan wrote:
I think the following code works. (inspirited from the sched_ttwu_pending()
in migration_call().)
if p-on_rq == 0 p-state == TASK_WAKING in __migrate_task() after this
patch,
it means the cpuallowed is changed before
On 06/03/2014 07:24 PM, Lai Jiangshan wrote:
> Hi, Jason
>
> Could you test again after the following command has done.
> (if Peter hasn't asked you test with this command before nor he doesn't stop
> you now)
>
> echo NO_TTWU_QUEUE > /sys/kernel/debug/sched_features
Off-topic!
Why
On 06/03/2014 10:16 PM, Peter Zijlstra wrote:
> On Tue, Jun 03, 2014 at 07:24:38PM +0800, Lai Jiangshan wrote:
>> Hi, Jason
>>
>> Could you test again after the following command has done.
>> (if Peter hasn't asked you test with this command before nor he doesn't stop
>> you now)
>>
>> echo
On 06/03/2014 10:28 PM, Peter Zijlstra wrote:
> On Tue, Jun 03, 2014 at 08:45:39PM +0800, Lai Jiangshan wrote:
>>
>> Hi, Peter,
>>
>> I rewrote the analyse. (scheduler_ipi() must be called before stopper-task,
>> so the part for workqueue of the old analyse maybe be wrong.)
>
> But I don't think
On Tue, Jun 03, 2014 at 08:45:39PM +0800, Lai Jiangshan wrote:
>
> Hi, Peter,
>
> I rewrote the analyse. (scheduler_ipi() must be called before stopper-task,
> so the part for workqueue of the old analyse maybe be wrong.)
But I don't think there is any guarantee we'll do the wakeup before
On Tue, Jun 03, 2014 at 07:24:38PM +0800, Lai Jiangshan wrote:
> Hi, Jason
>
> Could you test again after the following command has done.
> (if Peter hasn't asked you test with this command before nor he doesn't stop
> you now)
>
> echo NO_TTWU_QUEUE > /sys/kernel/debug/sched_features
>
>
Hi, Peter,
I rewrote the analyse. (scheduler_ipi() must be called before stopper-task,
so the part for workqueue of the old analyse maybe be wrong.)
I found something strange by review (just by review, no test yet)
int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask
Hi, Jason
Could you test again after the following command has done.
(if Peter hasn't asked you test with this command before nor he doesn't stop
you now)
echo NO_TTWU_QUEUE > /sys/kernel/debug/sched_features
Thanks a lot.
Hi, Peter,
I found something strange by review (just by review, no
Hi, Jason
Could you test again after the following command has done.
(if Peter hasn't asked you test with this command before nor he doesn't stop
you now)
echo NO_TTWU_QUEUE /sys/kernel/debug/sched_features
Thanks a lot.
Hi, Peter,
I found something strange by review (just by review, no
Hi, Peter,
I rewrote the analyse. (scheduler_ipi() must be called before stopper-task,
so the part for workqueue of the old analyse maybe be wrong.)
I found something strange by review (just by review, no test yet)
int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask
On Tue, Jun 03, 2014 at 07:24:38PM +0800, Lai Jiangshan wrote:
Hi, Jason
Could you test again after the following command has done.
(if Peter hasn't asked you test with this command before nor he doesn't stop
you now)
echo NO_TTWU_QUEUE /sys/kernel/debug/sched_features
Thanks a lot.
On Tue, Jun 03, 2014 at 08:45:39PM +0800, Lai Jiangshan wrote:
Hi, Peter,
I rewrote the analyse. (scheduler_ipi() must be called before stopper-task,
so the part for workqueue of the old analyse maybe be wrong.)
But I don't think there is any guarantee we'll do the wakeup before
running
On 06/03/2014 10:28 PM, Peter Zijlstra wrote:
On Tue, Jun 03, 2014 at 08:45:39PM +0800, Lai Jiangshan wrote:
Hi, Peter,
I rewrote the analyse. (scheduler_ipi() must be called before stopper-task,
so the part for workqueue of the old analyse maybe be wrong.)
But I don't think there is any
On 06/03/2014 10:16 PM, Peter Zijlstra wrote:
On Tue, Jun 03, 2014 at 07:24:38PM +0800, Lai Jiangshan wrote:
Hi, Jason
Could you test again after the following command has done.
(if Peter hasn't asked you test with this command before nor he doesn't stop
you now)
echo NO_TTWU_QUEUE
On 06/03/2014 07:24 PM, Lai Jiangshan wrote:
Hi, Jason
Could you test again after the following command has done.
(if Peter hasn't asked you test with this command before nor he doesn't stop
you now)
echo NO_TTWU_QUEUE /sys/kernel/debug/sched_features
Off-topic!
Why sched_features
On 05/27/2014 10:26 AM, Peter Zijlstra wrote:
On Tue, May 27, 2014 at 10:18:31AM -0400, Jason J. Herne wrote:
On 05/16/2014 12:29 PM, Peter Zijlstra wrote:
On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the
On 05/27/2014 10:26 AM, Peter Zijlstra wrote:
On Tue, May 27, 2014 at 10:18:31AM -0400, Jason J. Herne wrote:
On 05/16/2014 12:29 PM, Peter Zijlstra wrote:
On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the
On Tue, May 27, 2014 at 10:18:31AM -0400, Jason J. Herne wrote:
> On 05/16/2014 12:29 PM, Peter Zijlstra wrote:
> >On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
> >>so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the first
> >>place to fix.
> >
> >I'm not arguing
On 05/16/2014 12:29 PM, Peter Zijlstra wrote:
On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the first
place to fix.
I'm not arguing about that, not to mention that this is userspace
exposed and nobody protects
On 05/16/2014 12:29 PM, Peter Zijlstra wrote:
On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the first
place to fix.
I'm not arguing about that, not to mention that this is userspace
exposed and nobody protects
On Tue, May 27, 2014 at 10:18:31AM -0400, Jason J. Herne wrote:
On 05/16/2014 12:29 PM, Peter Zijlstra wrote:
On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the first
place to fix.
I'm not arguing about that,
On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
> so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the first
> place to fix.
I'm not arguing about that, not to mention that this is userspace
exposed and nobody protects that.
But I was expecting kernel stuff that
On Fri, May 16, 2014 at 7:57 PM, Peter Zijlstra wrote:
> On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
>> Hi, Peter and other scheduler Gurus:
>>
>> When I was trying to test wq-VS-hotplug, I always hit a problem in scheduler
>> with the following WARNING:
>>
>> [ 74.765519]
On Fri, May 16, 2014 at 02:14:05PM +0200, Thomas Gleixner wrote:
> On Fri, 16 May 2014, Tejun Heo wrote:
> > On Fri, May 16, 2014 at 01:57:37PM +0200, Peter Zijlstra wrote:
> > > This of course leaves the question how the workqueue code manages to
> > > call set_cpu_allowed_ptr() on a cpu _before_
On Fri, 16 May 2014, Tejun Heo wrote:
> On Fri, May 16, 2014 at 01:57:37PM +0200, Peter Zijlstra wrote:
> > This of course leaves the question how the workqueue code manages to
> > call set_cpu_allowed_ptr() on a cpu _before_ its online.
> >
> > That too sounds fishy.. with the proposed patch the
Hello, Peter.
On Fri, May 16, 2014 at 01:57:37PM +0200, Peter Zijlstra wrote:
> This of course leaves the question how the workqueue code manages to
> call set_cpu_allowed_ptr() on a cpu _before_ its online.
>
> That too sounds fishy.. with the proposed patch the
> set_cpus_allowed_ptr() will
On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
> Hi, Peter and other scheduler Gurus:
>
> When I was trying to test wq-VS-hotplug, I always hit a problem in scheduler
> with the following WARNING:
>
> [ 74.765519] WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124
>
On Fri, May 16, 2014 at 12:16:43PM +0200, Peter Zijlstra wrote:
> On Fri, May 16, 2014 at 12:15:05PM +0200, Peter Zijlstra wrote:
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -5126,7 +5126,6 @@ static int sched_cpu_active(struct notif
> >
On Fri, May 16, 2014 at 05:56:10PM +0800, Lai Jiangshan wrote:
> On 05/16/2014 05:35 PM, Peter Zijlstra wrote:
> > On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
> >> After debugging, I found the hotlug-in cpu is atctive but !online in this
> >> case.
> >> the problem was
On Fri, May 16, 2014 at 12:15:05PM +0200, Peter Zijlstra wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5126,7 +5126,6 @@ static int sched_cpu_active(struct notif
> unsigned long action, void *hcpu)
> {
> switch (action &
On Fri, May 16, 2014 at 11:35:30AM +0200, Peter Zijlstra wrote:
> On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
> > After debugging, I found the hotlug-in cpu is atctive but !online in this
> > case.
> > the problem was introduced by 5fbd036b.
> > Some code assumes that any cpu
On 05/16/2014 05:35 PM, Peter Zijlstra wrote:
> On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
>> After debugging, I found the hotlug-in cpu is atctive but !online in this
>> case.
>> the problem was introduced by 5fbd036b.
>> Some code assumes that any cpu in cpu_active_mask is
On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
> After debugging, I found the hotlug-in cpu is atctive but !online in this
> case.
> the problem was introduced by 5fbd036b.
> Some code assumes that any cpu in cpu_active_mask is also online, but
> 5fbd036b breaks
> this
On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
After debugging, I found the hotlug-in cpu is atctive but !online in this
case.
the problem was introduced by 5fbd036b.
Some code assumes that any cpu in cpu_active_mask is also online, but
5fbd036b breaks
this assumption, so
On 05/16/2014 05:35 PM, Peter Zijlstra wrote:
On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
After debugging, I found the hotlug-in cpu is atctive but !online in this
case.
the problem was introduced by 5fbd036b.
Some code assumes that any cpu in cpu_active_mask is also
On Fri, May 16, 2014 at 11:35:30AM +0200, Peter Zijlstra wrote:
On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
After debugging, I found the hotlug-in cpu is atctive but !online in this
case.
the problem was introduced by 5fbd036b.
Some code assumes that any cpu in
On Fri, May 16, 2014 at 12:15:05PM +0200, Peter Zijlstra wrote:
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5126,7 +5126,6 @@ static int sched_cpu_active(struct notif
unsigned long action, void *hcpu)
{
switch (action ~CPU_TASKS_FROZEN)
On Fri, May 16, 2014 at 05:56:10PM +0800, Lai Jiangshan wrote:
On 05/16/2014 05:35 PM, Peter Zijlstra wrote:
On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
After debugging, I found the hotlug-in cpu is atctive but !online in this
case.
the problem was introduced by
On Fri, May 16, 2014 at 12:16:43PM +0200, Peter Zijlstra wrote:
On Fri, May 16, 2014 at 12:15:05PM +0200, Peter Zijlstra wrote:
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5126,7 +5126,6 @@ static int sched_cpu_active(struct notif
unsigned
On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
Hi, Peter and other scheduler Gurus:
When I was trying to test wq-VS-hotplug, I always hit a problem in scheduler
with the following WARNING:
[ 74.765519] WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124
Hello, Peter.
On Fri, May 16, 2014 at 01:57:37PM +0200, Peter Zijlstra wrote:
This of course leaves the question how the workqueue code manages to
call set_cpu_allowed_ptr() on a cpu _before_ its online.
That too sounds fishy.. with the proposed patch the
set_cpus_allowed_ptr() will
On Fri, 16 May 2014, Tejun Heo wrote:
On Fri, May 16, 2014 at 01:57:37PM +0200, Peter Zijlstra wrote:
This of course leaves the question how the workqueue code manages to
call set_cpu_allowed_ptr() on a cpu _before_ its online.
That too sounds fishy.. with the proposed patch the
On Fri, May 16, 2014 at 02:14:05PM +0200, Thomas Gleixner wrote:
On Fri, 16 May 2014, Tejun Heo wrote:
On Fri, May 16, 2014 at 01:57:37PM +0200, Peter Zijlstra wrote:
This of course leaves the question how the workqueue code manages to
call set_cpu_allowed_ptr() on a cpu _before_ its
On Fri, May 16, 2014 at 7:57 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, May 16, 2014 at 11:50:42AM +0800, Lai Jiangshan wrote:
Hi, Peter and other scheduler Gurus:
When I was trying to test wq-VS-hotplug, I always hit a problem in scheduler
with the following WARNING:
[
On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the first
place to fix.
I'm not arguing about that, not to mention that this is userspace
exposed and nobody protects that.
But I was expecting kernel stuff that
On 05/15/2014 12:52 AM, Jason J. Herne wrote:
> On 05/12/2014 10:17 PM, Sasha Levin wrote:
>> I don't have an easy way to reproduce it as I only saw the bug once, but
>> it happened when I started pressuring CPU hotplug paths by adding and
>> removing
>> CPUs often. Maybe it has anything to do
On 05/15/2014 12:52 AM, Jason J. Herne wrote:
On 05/12/2014 10:17 PM, Sasha Levin wrote:
I don't have an easy way to reproduce it as I only saw the bug once, but
it happened when I started pressuring CPU hotplug paths by adding and
removing
CPUs often. Maybe it has anything to do with that?
On 05/12/2014 10:17 PM, Sasha Levin wrote:
I don't have an easy way to reproduce it as I only saw the bug once, but
it happened when I started pressuring CPU hotplug paths by adding and removing
CPUs often. Maybe it has anything to do with that?
As per the original report
On 05/12/2014 10:17 PM, Sasha Levin wrote:
I don't have an easy way to reproduce it as I only saw the bug once, but
it happened when I started pressuring CPU hotplug paths by adding and removing
CPUs often. Maybe it has anything to do with that?
As per the original report
On 05/12/2014 10:19 PM, Lai Jiangshan wrote:
> On 05/13/2014 04:01 AM, Tejun Heo wrote:
>> > On Mon, May 12, 2014 at 02:58:55PM -0400, Sasha Levin wrote:
>>> >> Hi all,
>>> >>
>>> >> While fuzzing with trinity inside a KVM tools guest running the latest
>>> >> -next
>>> >> kernel I've stumbled on
On 05/13/2014 04:01 AM, Tejun Heo wrote:
> On Mon, May 12, 2014 at 02:58:55PM -0400, Sasha Levin wrote:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running the latest -next
>> kernel I've stumbled on the following spew:
>>
>> [ 1297.886670] WARNING: CPU: 0 PID: 190 at
On Mon, May 12, 2014 at 02:58:55PM -0400, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
>
> [ 1297.886670] WARNING: CPU: 0 PID: 190 at kernel/workqueue.c:2176
>
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1297.886670] WARNING: CPU: 0 PID: 190 at kernel/workqueue.c:2176
process_one_work+0xb5/0x6f0()
[ 1297.889216] Modules linked in:
[ 1297.890306] CPU: 0 PID: 190
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1297.886670] WARNING: CPU: 0 PID: 190 at kernel/workqueue.c:2176
process_one_work+0xb5/0x6f0()
[ 1297.889216] Modules linked in:
[ 1297.890306] CPU: 0 PID: 190
On Mon, May 12, 2014 at 02:58:55PM -0400, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1297.886670] WARNING: CPU: 0 PID: 190 at kernel/workqueue.c:2176
process_one_work+0xb5/0x6f0()
On 05/13/2014 04:01 AM, Tejun Heo wrote:
On Mon, May 12, 2014 at 02:58:55PM -0400, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1297.886670] WARNING: CPU: 0 PID: 190 at
On 05/12/2014 10:19 PM, Lai Jiangshan wrote:
On 05/13/2014 04:01 AM, Tejun Heo wrote:
On Mon, May 12, 2014 at 02:58:55PM -0400, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest
-next
kernel I've stumbled on the following spew:
[
88 matches
Mail list logo
