On 15 January 2014 17:04, Peter Zijlstra wrote:
> On Wed, Jan 15, 2014 at 04:17:26PM +0530, Viresh Kumar wrote:
>> On 15 January 2014 16:08, Peter Zijlstra wrote:
>> > Nah, its just ugly and we should fix it. You need to be careful to not
>> > place tasks in a cpuset you're going to unplug
On 15 January 2014 17:04, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Jan 15, 2014 at 04:17:26PM +0530, Viresh Kumar wrote:
On 15 January 2014 16:08, Peter Zijlstra pet...@infradead.org wrote:
Nah, its just ugly and we should fix it. You need to be careful to not
place tasks in a
On Tue, Feb 11, 2014 at 02:22:43PM +0530, Viresh Kumar wrote:
> On 28 January 2014 18:53, Frederic Weisbecker wrote:
> > No, when a single task is running on a full dynticks CPU, the tick is
> > supposed to run
> > every seconds. I'm actually suprised it doesn't happen in your traces, did
> >
On Tue, Feb 11, 2014 at 02:22:43PM +0530, Viresh Kumar wrote:
On 28 January 2014 18:53, Frederic Weisbecker fweis...@gmail.com wrote:
No, when a single task is running on a full dynticks CPU, the tick is
supposed to run
every seconds. I'm actually suprised it doesn't happen in your traces,
On 28 January 2014 18:53, Frederic Weisbecker wrote:
> No, when a single task is running on a full dynticks CPU, the tick is
> supposed to run
> every seconds. I'm actually suprised it doesn't happen in your traces, did
> you tweak
> something specific?
Why do we need this 1 second tick
On 28 January 2014 18:53, Frederic Weisbecker fweis...@gmail.com wrote:
No, when a single task is running on a full dynticks CPU, the tick is
supposed to run
every seconds. I'm actually suprised it doesn't happen in your traces, did
you tweak
something specific?
Why do we need this 1
On 28 January 2014 21:41, Kevin Hilman wrote:
> I think Viresh is using my patch/hack to configure/disable the 1Hz
> residual tick.
Yeah. I am using sched_tick_max_deferment by setting it to -1. Why
do we need a timer every second for NO_HZ_FULL currently?
--
To unsubscribe from this list: send
On 28 January 2014 21:41, Kevin Hilman khil...@linaro.org wrote:
I think Viresh is using my patch/hack to configure/disable the 1Hz
residual tick.
Yeah. I am using sched_tick_max_deferment by setting it to -1. Why
do we need a timer every second for NO_HZ_FULL currently?
--
To unsubscribe from
On Tue, Jan 28, 2014 at 5:23 AM, Frederic Weisbecker wrote:
> On Fri, Jan 24, 2014 at 10:51:14AM +0530, Viresh Kumar wrote:
>> On 23 January 2014 20:28, Frederic Weisbecker wrote:
>> > On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
>>
>> >> So, the main problem in my case was
On Fri, Jan 24, 2014 at 10:51:14AM +0530, Viresh Kumar wrote:
> On 23 January 2014 20:28, Frederic Weisbecker wrote:
> > On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
>
> >> So, the main problem in my case was caused by this:
> >>
> >><...>-2147 [001] d..2
On Fri, Jan 24, 2014 at 10:51:14AM +0530, Viresh Kumar wrote:
On 23 January 2014 20:28, Frederic Weisbecker fweis...@gmail.com wrote:
On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
So, the main problem in my case was caused by this:
...-2147 [001] d..2
On Tue, Jan 28, 2014 at 5:23 AM, Frederic Weisbecker fweis...@gmail.com wrote:
On Fri, Jan 24, 2014 at 10:51:14AM +0530, Viresh Kumar wrote:
On 23 January 2014 20:28, Frederic Weisbecker fweis...@gmail.com wrote:
On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
So, the main
On 23 January 2014 19:31, Frederic Weisbecker wrote:
> Ok, so it is fine to migrate the latter kind I guess?
Unless somebody has abused the API and used bound workqueues where he
should have used unbound ones.
> I haven't checked the details but then this quiesce option would involve
> a
On Fri, 2014-01-24 at 10:51 +0530, Viresh Kumar wrote:
> On 23 January 2014 20:28, Frederic Weisbecker wrote:
> > On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
>
> >> So, the main problem in my case was caused by this:
> >>
> >><...>-2147 [001] d..2 302.573881:
On Fri, 2014-01-24 at 10:51 +0530, Viresh Kumar wrote:
On 23 January 2014 20:28, Frederic Weisbecker fweis...@gmail.com wrote:
On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
So, the main problem in my case was caused by this:
...-2147 [001] d..2 302.573881:
On 23 January 2014 19:31, Frederic Weisbecker fweis...@gmail.com wrote:
Ok, so it is fine to migrate the latter kind I guess?
Unless somebody has abused the API and used bound workqueues where he
should have used unbound ones.
I haven't checked the details but then this quiesce option would
On 23 January 2014 20:28, Frederic Weisbecker wrote:
> On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
>> So, the main problem in my case was caused by this:
>>
>><...>-2147 [001] d..2 302.573881: hrtimer_start:
>> hrtimer=c172aa50 function=tick_sched_timer
On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
> On 20 January 2014 21:21, Frederic Weisbecker wrote:
> > I fear you can't. If you schedule a timer in 4 seconds away and your
> > clockdevice
> > can only count up to 2 seconds, you can't help much the interrupt in the
> > middle
On 23 January 2014 19:24, Frederic Weisbecker wrote:
> On Tue, Jan 21, 2014 at 10:07:58AM +0800, Lei Wen wrote:
>> I find the cpuset's cpus member becomes NULL even I hotplug the core3
>> back again.
>> So is it a bug?
>
> Not sure, you may need to check cpuset internals.
I think this is the
On Tue, Jan 21, 2014 at 03:19:36PM +0530, Viresh Kumar wrote:
> On 20 January 2014 21:11, Frederic Weisbecker wrote:
> > But for workqueues having a global affinity, I think they can be
> > rescheduled later
> > on the old CPUs. Although I'm not sure about that, I'm Cc'ing Tejun.
>
> Works
On Tue, Jan 21, 2014 at 10:07:58AM +0800, Lei Wen wrote:
> On Mon, Jan 20, 2014 at 11:41 PM, Frederic Weisbecker
> wrote:
> > On Mon, Jan 20, 2014 at 08:30:10PM +0530, Viresh Kumar wrote:
> >> On 20 January 2014 19:29, Lei Wen wrote:
> >> > Hi Viresh,
> >>
> >> Hi Lei,
> >>
> >> > I have one
On Tue, Jan 21, 2014 at 10:07:58AM +0800, Lei Wen wrote:
On Mon, Jan 20, 2014 at 11:41 PM, Frederic Weisbecker
fweis...@gmail.com wrote:
On Mon, Jan 20, 2014 at 08:30:10PM +0530, Viresh Kumar wrote:
On 20 January 2014 19:29, Lei Wen adrian.w...@gmail.com wrote:
Hi Viresh,
Hi Lei,
On Tue, Jan 21, 2014 at 03:19:36PM +0530, Viresh Kumar wrote:
On 20 January 2014 21:11, Frederic Weisbecker fweis...@gmail.com wrote:
But for workqueues having a global affinity, I think they can be
rescheduled later
on the old CPUs. Although I'm not sure about that, I'm Cc'ing Tejun.
On 23 January 2014 19:24, Frederic Weisbecker fweis...@gmail.com wrote:
On Tue, Jan 21, 2014 at 10:07:58AM +0800, Lei Wen wrote:
I find the cpuset's cpus member becomes NULL even I hotplug the core3
back again.
So is it a bug?
Not sure, you may need to check cpuset internals.
I think this
On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
On 20 January 2014 21:21, Frederic Weisbecker fweis...@gmail.com wrote:
I fear you can't. If you schedule a timer in 4 seconds away and your
clockdevice
can only count up to 2 seconds, you can't help much the interrupt in the
On 23 January 2014 20:28, Frederic Weisbecker fweis...@gmail.com wrote:
On Tue, Jan 21, 2014 at 04:03:53PM +0530, Viresh Kumar wrote:
So, the main problem in my case was caused by this:
...-2147 [001] d..2 302.573881: hrtimer_start:
hrtimer=c172aa50 function=tick_sched_timer
On 20 January 2014 21:21, Frederic Weisbecker wrote:
> I fear you can't. If you schedule a timer in 4 seconds away and your
> clockdevice
> can only count up to 2 seconds, you can't help much the interrupt in the
> middle to
> cope with the overflow.
>
> So you need to act on the source of the
On 21 January 2014 07:37, Lei Wen wrote:
> What is more, I also did similiar test, and find when I set two such
> cpuset group,
> like core 0-2 to cpuset1, core 3 to cpuset2, while hotunplug the core3
> afterwise.
> I find the cpuset's cpus member becomes NULL even I hotplug the core3
> back
On 20 January 2014 21:11, Frederic Weisbecker wrote:
> But for workqueues having a global affinity, I think they can be rescheduled
> later
> on the old CPUs. Although I'm not sure about that, I'm Cc'ing Tejun.
Works queued on workqueues with WQ_UNBOUND flag set are run on any cpu
and is
On 20 January 2014 21:11, Frederic Weisbecker fweis...@gmail.com wrote:
But for workqueues having a global affinity, I think they can be rescheduled
later
on the old CPUs. Although I'm not sure about that, I'm Cc'ing Tejun.
Works queued on workqueues with WQ_UNBOUND flag set are run on any
On 21 January 2014 07:37, Lei Wen adrian.w...@gmail.com wrote:
What is more, I also did similiar test, and find when I set two such
cpuset group,
like core 0-2 to cpuset1, core 3 to cpuset2, while hotunplug the core3
afterwise.
I find the cpuset's cpus member becomes NULL even I hotplug the
On 20 January 2014 21:21, Frederic Weisbecker fweis...@gmail.com wrote:
I fear you can't. If you schedule a timer in 4 seconds away and your
clockdevice
can only count up to 2 seconds, you can't help much the interrupt in the
middle to
cope with the overflow.
So you need to act on the
On Mon, Jan 20, 2014 at 11:41 PM, Frederic Weisbecker
wrote:
> On Mon, Jan 20, 2014 at 08:30:10PM +0530, Viresh Kumar wrote:
>> On 20 January 2014 19:29, Lei Wen wrote:
>> > Hi Viresh,
>>
>> Hi Lei,
>>
>> > I have one question regarding unbounded workqueue migration in your case.
>> > You use
On Mon, Jan 20, 2014 at 05:00:20PM +0530, Viresh Kumar wrote:
> On 16 January 2014 15:16, Thomas Gleixner wrote:
> > Just do the math.
> >
> > max reload value / timer freq = max time span
>
> Thanks.
>
> > So:
> >
> > 0x7fff / 24MHz = 89.478485 sec
> >
> > Nothing to do here
On Mon, Jan 20, 2014 at 08:30:10PM +0530, Viresh Kumar wrote:
> On 20 January 2014 19:29, Lei Wen wrote:
> > Hi Viresh,
>
> Hi Lei,
>
> > I have one question regarding unbounded workqueue migration in your case.
> > You use hotplug to migrate the unbounded work to other cpus, but its cpu
> >
On 20 January 2014 19:29, Lei Wen wrote:
> Hi Viresh,
Hi Lei,
> I have one question regarding unbounded workqueue migration in your case.
> You use hotplug to migrate the unbounded work to other cpus, but its cpu mask
> would still be 0xf, since cannot be changed by cpuset.
>
> My question is
Hi Viresh,
On Wed, Jan 15, 2014 at 5:27 PM, Viresh Kumar wrote:
> Hi Again,
>
> I am now successful in isolating a CPU completely using CPUsets,
> NO_HZ_FULL and CPU hotplug..
>
> My setup and requirements for those who weren't following the
> earlier mails:
>
> For networking machines it is
On 16 January 2014 15:16, Thomas Gleixner wrote:
> Just do the math.
>
> max reload value / timer freq = max time span
Thanks.
> So:
>
> 0x7fff / 24MHz = 89.478485 sec
>
> Nothing to do here except to get rid of the requirement to arm the
> timer at all.
@Frederic: Any inputs on
Hi Viresh,
On Wed, Jan 15, 2014 at 5:27 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
Hi Again,
I am now successful in isolating a CPU completely using CPUsets,
NO_HZ_FULL and CPU hotplug..
My setup and requirements for those who weren't following the
earlier mails:
For networking
On 20 January 2014 19:29, Lei Wen adrian.w...@gmail.com wrote:
Hi Viresh,
Hi Lei,
I have one question regarding unbounded workqueue migration in your case.
You use hotplug to migrate the unbounded work to other cpus, but its cpu mask
would still be 0xf, since cannot be changed by cpuset.
On Mon, Jan 20, 2014 at 08:30:10PM +0530, Viresh Kumar wrote:
On 20 January 2014 19:29, Lei Wen adrian.w...@gmail.com wrote:
Hi Viresh,
Hi Lei,
I have one question regarding unbounded workqueue migration in your case.
You use hotplug to migrate the unbounded work to other cpus, but its
On Mon, Jan 20, 2014 at 05:00:20PM +0530, Viresh Kumar wrote:
On 16 January 2014 15:16, Thomas Gleixner t...@linutronix.de wrote:
Just do the math.
max reload value / timer freq = max time span
Thanks.
So:
0x7fff / 24MHz = 89.478485 sec
Nothing to do here except
On Mon, Jan 20, 2014 at 11:41 PM, Frederic Weisbecker
fweis...@gmail.com wrote:
On Mon, Jan 20, 2014 at 08:30:10PM +0530, Viresh Kumar wrote:
On 20 January 2014 19:29, Lei Wen adrian.w...@gmail.com wrote:
Hi Viresh,
Hi Lei,
I have one question regarding unbounded workqueue migration in
On 16 January 2014 15:16, Thomas Gleixner t...@linutronix.de wrote:
Just do the math.
max reload value / timer freq = max time span
Thanks.
So:
0x7fff / 24MHz = 89.478485 sec
Nothing to do here except to get rid of the requirement to arm the
timer at all.
@Frederic: Any
On Thu, 16 Jan 2014, Viresh Kumar wrote:
> On 15 January 2014 22:47, Frederic Weisbecker wrote:
> > Are you sure about that? NO_HZ_FULL shouldn't touch much hrtimers.
> > Those are independant from the tick.
> >
> > Although some of them seem to rely on the softirq, but that seem to
> > concern
On Thu, 16 Jan 2014, Viresh Kumar wrote:
On 15 January 2014 22:47, Frederic Weisbecker fweis...@gmail.com wrote:
Are you sure about that? NO_HZ_FULL shouldn't touch much hrtimers.
Those are independant from the tick.
Although some of them seem to rely on the softirq, but that seem to
On Wed, Jan 15, 2014 at 02:57:36PM +0530, Viresh Kumar wrote:
> Hi Again,
>
> I am now successful in isolating a CPU completely using CPUsets,
> NO_HZ_FULL and CPU hotplug..
>
> My setup and requirements for those who weren't following the
> earlier mails:
>
> For networking machines it is
On Wed, Jan 15, 2014 at 04:17:26PM +0530, Viresh Kumar wrote:
> On 15 January 2014 16:08, Peter Zijlstra wrote:
> > Nah, its just ugly and we should fix it. You need to be careful to not
> > place tasks in a cpuset you're going to unplug though, that'll give
> > funny results.
>
> Okay. So how
On 15 January 2014 16:08, Peter Zijlstra wrote:
> Nah, its just ugly and we should fix it. You need to be careful to not
> place tasks in a cpuset you're going to unplug though, that'll give
> funny results.
Okay. So how do you suggest to get rid of cases like a work queued
on CPU1 initially and
On Wed, Jan 15, 2014 at 02:57:36PM +0530, Viresh Kumar wrote:
> Hi Again,
>
> I am now successful in isolating a CPU completely using CPUsets,
> NO_HZ_FULL and CPU hotplug..
>
> My setup and requirements for those who weren't following the
> earlier mails:
>
> For networking machines it is
On Wed, Jan 15, 2014 at 02:57:36PM +0530, Viresh Kumar wrote:
Hi Again,
I am now successful in isolating a CPU completely using CPUsets,
NO_HZ_FULL and CPU hotplug..
My setup and requirements for those who weren't following the
earlier mails:
For networking machines it is required to
On 15 January 2014 16:08, Peter Zijlstra pet...@infradead.org wrote:
Nah, its just ugly and we should fix it. You need to be careful to not
place tasks in a cpuset you're going to unplug though, that'll give
funny results.
Okay. So how do you suggest to get rid of cases like a work queued
on
On Wed, Jan 15, 2014 at 04:17:26PM +0530, Viresh Kumar wrote:
On 15 January 2014 16:08, Peter Zijlstra pet...@infradead.org wrote:
Nah, its just ugly and we should fix it. You need to be careful to not
place tasks in a cpuset you're going to unplug though, that'll give
funny results.
On Wed, Jan 15, 2014 at 02:57:36PM +0530, Viresh Kumar wrote:
Hi Again,
I am now successful in isolating a CPU completely using CPUsets,
NO_HZ_FULL and CPU hotplug..
My setup and requirements for those who weren't following the
earlier mails:
For networking machines it is required to
54 matches
Mail list logo
