On Wed, May 14, 2014 at 01:30:39AM +0200, Frederic Weisbecker wrote:
> On Fri, May 09, 2014 at 02:14:10PM +0530, Viresh Kumar wrote:
> > On 23 April 2014 16:42, Viresh Kumar wrote:
> > > On 15 April 2014 15:00, Frederic Weisbecker wrote:
> > >> Ok, I'm a bit buzy with a conference right now but
On Wed, May 14, 2014 at 01:30:39AM +0200, Frederic Weisbecker wrote:
On Fri, May 09, 2014 at 02:14:10PM +0530, Viresh Kumar wrote:
On 23 April 2014 16:42, Viresh Kumar viresh.ku...@linaro.org wrote:
On 15 April 2014 15:00, Frederic Weisbecker fweis...@gmail.com wrote:
Ok, I'm a bit buzy
On Fri, May 09, 2014 at 02:14:10PM +0530, Viresh Kumar wrote:
> On 23 April 2014 16:42, Viresh Kumar wrote:
> > On 15 April 2014 15:00, Frederic Weisbecker wrote:
> >> Ok, I'm a bit buzy with a conference right now but I'm going to summarize
> >> that
> >> soonish.
>
> Hi Frederic,
>
> Please
On Fri, May 09, 2014 at 02:14:10PM +0530, Viresh Kumar wrote:
On 23 April 2014 16:42, Viresh Kumar viresh.ku...@linaro.org wrote:
On 15 April 2014 15:00, Frederic Weisbecker fweis...@gmail.com wrote:
Ok, I'm a bit buzy with a conference right now but I'm going to summarize
that
soonish.
On 23 April 2014 16:42, Viresh Kumar wrote:
> On 15 April 2014 15:00, Frederic Weisbecker wrote:
>> Ok, I'm a bit buzy with a conference right now but I'm going to summarize
>> that
>> soonish.
Hi Frederic,
Please see if you can find some time to close this, that would be very
helpful :)
On 23 April 2014 16:42, Viresh Kumar viresh.ku...@linaro.org wrote:
On 15 April 2014 15:00, Frederic Weisbecker fweis...@gmail.com wrote:
Ok, I'm a bit buzy with a conference right now but I'm going to summarize
that
soonish.
Hi Frederic,
Please see if you can find some time to close this,
On 15 April 2014 15:00, Frederic Weisbecker wrote:
> Ok, I'm a bit buzy with a conference right now but I'm going to summarize that
> soonish.
Are you back now ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 15 April 2014 15:00, Frederic Weisbecker fweis...@gmail.com wrote:
Ok, I'm a bit buzy with a conference right now but I'm going to summarize that
soonish.
Are you back now ?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Tue, Apr 15, 2014 at 12:52:26PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 15, 2014 at 11:30:04AM +0200, Frederic Weisbecker wrote:
> > There is probably a few things that assume local calls but last time
> > I checked I had the impression that it was fairly possible to call
> >
On Tue, Apr 15, 2014 at 11:30:04AM +0200, Frederic Weisbecker wrote:
> There is probably a few things that assume local calls but last time
> I checked I had the impression that it was fairly possible to call
> sched_class::task_tick()
> remotely. rq is locked, no reference to "current", use rq
On Mon, Apr 14, 2014 at 02:06:00PM +0200, Peter Zijlstra wrote:
> On Mon, Apr 14, 2014 at 05:22:30PM +0530, Viresh Kumar wrote:
> > On 14 April 2014 17:17, Peter Zijlstra wrote:
> > > What causes this tick? I was under the impression that once there's a
> > > single task (not doing any syscalls)
On 14 April 2014 17:36, Peter Zijlstra wrote:
> That's a bit of a non-answer. I'm fairly sure its not a gazillion
> issues, since the actual scheduler tick doesn't actually do that much.
>
> So start by enumerating what is actually required.
>
> The 2), which I suppose you're now trying to
On 14 April 2014 17:36, Peter Zijlstra pet...@infradead.org wrote:
That's a bit of a non-answer. I'm fairly sure its not a gazillion
issues, since the actual scheduler tick doesn't actually do that much.
So start by enumerating what is actually required.
The 2), which I suppose you're now
On Mon, Apr 14, 2014 at 02:06:00PM +0200, Peter Zijlstra wrote:
On Mon, Apr 14, 2014 at 05:22:30PM +0530, Viresh Kumar wrote:
On 14 April 2014 17:17, Peter Zijlstra pet...@infradead.org wrote:
What causes this tick? I was under the impression that once there's a
single task (not doing any
On Tue, Apr 15, 2014 at 11:30:04AM +0200, Frederic Weisbecker wrote:
There is probably a few things that assume local calls but last time
I checked I had the impression that it was fairly possible to call
sched_class::task_tick()
remotely. rq is locked, no reference to current, use rq
On Tue, Apr 15, 2014 at 12:52:26PM +0200, Peter Zijlstra wrote:
On Tue, Apr 15, 2014 at 11:30:04AM +0200, Frederic Weisbecker wrote:
There is probably a few things that assume local calls but last time
I checked I had the impression that it was fairly possible to call
On Mon, Apr 14, 2014 at 05:22:30PM +0530, Viresh Kumar wrote:
> On 14 April 2014 17:17, Peter Zijlstra wrote:
> > What causes this tick? I was under the impression that once there's a
> > single task (not doing any syscalls) and the above issues are sorted, no
> > more tick would happen.
>
>
On 14 April 2014 17:17, Peter Zijlstra wrote:
> What causes this tick? I was under the impression that once there's a
> single task (not doing any syscalls) and the above issues are sorted, no
> more tick would happen.
This is what Frederic told me earlier:
https://lkml.org/lkml/2014/2/13/238
On Mon, Apr 14, 2014 at 05:12:08PM +0530, Viresh Kumar wrote:
> On 14 April 2014 16:32, Peter Zijlstra wrote:
> > I'm still not sure _what_ you're trying to solve here. What are you
> > doing and why?
>
> Hi Peter,
>
> We are working building ARM Networking machines. Networking Data
> plane is
On 14 April 2014 16:32, Peter Zijlstra wrote:
> I'm still not sure _what_ you're trying to solve here. What are you
> doing and why?
Hi Peter,
We are working building ARM Networking machines. Networking Data
plane is handled completely at user space. At run time we may fix
any number of CPUs
On Fri, Apr 11, 2014 at 10:08:30PM +0530, Viresh Kumar wrote:
> On 11 April 2014 20:48, Peter Zijlstra wrote:
> > On Fri, Apr 11, 2014 at 04:53:35PM +0200, Frederic Weisbecker wrote:
>
> > I think there's assumptions that tick runs on the local cpu;
>
> Yes, many function behave that way, i.e.
On 14 April 2014 15:18, Preeti Murthy wrote:
> I am not too sure about the complexity or the worthiness of this patch but
> just wanted to add that care must be taken to migrate the tick_sched_timer
> of all the remote CPUs off a hotplugged out CPU if the latter was keeping
> their time thus far.
Hi Viresh,
I am not too sure about the complexity or the worthiness of this patch but
just wanted to add that care must be taken to migrate the tick_sched_timer
of all the remote CPUs off a hotplugged out CPU if the latter was keeping
their time thus far. In the normal scenario I am guessing the
Hi Viresh,
I am not too sure about the complexity or the worthiness of this patch but
just wanted to add that care must be taken to migrate the tick_sched_timer
of all the remote CPUs off a hotplugged out CPU if the latter was keeping
their time thus far. In the normal scenario I am guessing the
On 14 April 2014 15:18, Preeti Murthy preeti.l...@gmail.com wrote:
I am not too sure about the complexity or the worthiness of this patch but
just wanted to add that care must be taken to migrate the tick_sched_timer
of all the remote CPUs off a hotplugged out CPU if the latter was keeping
On Fri, Apr 11, 2014 at 10:08:30PM +0530, Viresh Kumar wrote:
On 11 April 2014 20:48, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Apr 11, 2014 at 04:53:35PM +0200, Frederic Weisbecker wrote:
I think there's assumptions that tick runs on the local cpu;
Yes, many function behave
On 14 April 2014 16:32, Peter Zijlstra pet...@infradead.org wrote:
I'm still not sure _what_ you're trying to solve here. What are you
doing and why?
Hi Peter,
We are working building ARM Networking machines. Networking Data
plane is handled completely at user space. At run time we may fix
any
On Mon, Apr 14, 2014 at 05:12:08PM +0530, Viresh Kumar wrote:
On 14 April 2014 16:32, Peter Zijlstra pet...@infradead.org wrote:
I'm still not sure _what_ you're trying to solve here. What are you
doing and why?
Hi Peter,
We are working building ARM Networking machines. Networking Data
On 14 April 2014 17:17, Peter Zijlstra pet...@infradead.org wrote:
What causes this tick? I was under the impression that once there's a
single task (not doing any syscalls) and the above issues are sorted, no
more tick would happen.
This is what Frederic told me earlier:
On Mon, Apr 14, 2014 at 05:22:30PM +0530, Viresh Kumar wrote:
On 14 April 2014 17:17, Peter Zijlstra pet...@infradead.org wrote:
What causes this tick? I was under the impression that once there's a
single task (not doing any syscalls) and the above issues are sorted, no
more tick would
On 11 April 2014 20:48, Peter Zijlstra wrote:
> On Fri, Apr 11, 2014 at 04:53:35PM +0200, Frederic Weisbecker wrote:
> I think there's assumptions that tick runs on the local cpu;
Yes, many function behave that way, i.e. with smp_processor_id() as
CPU.
> also what
> are you going to do when
On Fri, Apr 11, 2014 at 04:53:35PM +0200, Frederic Weisbecker wrote:
> On Fri, Apr 11, 2014 at 03:34:23PM +0530, Viresh Kumar wrote:
> > On 10 April 2014 20:09, Frederic Weisbecker wrote:
> > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > > index 9f8af69..1e2d6b7 100644
>
On Fri, Apr 11, 2014 at 03:34:23PM +0530, Viresh Kumar wrote:
> On 10 April 2014 20:09, Frederic Weisbecker wrote:
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 9f8af69..1e2d6b7 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@
On 10 April 2014 20:09, Frederic Weisbecker wrote:
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 9f8af69..1e2d6b7 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -202,13 +202,16 @@ static void tick_nohz_restart_sched_tick(struct
>
On 10 April 2014 20:09, Frederic Weisbecker fweis...@gmail.com wrote:
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 9f8af69..1e2d6b7 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -202,13 +202,16 @@ static void
On Fri, Apr 11, 2014 at 03:34:23PM +0530, Viresh Kumar wrote:
On 10 April 2014 20:09, Frederic Weisbecker fweis...@gmail.com wrote:
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 9f8af69..1e2d6b7 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
On Fri, Apr 11, 2014 at 04:53:35PM +0200, Frederic Weisbecker wrote:
On Fri, Apr 11, 2014 at 03:34:23PM +0530, Viresh Kumar wrote:
On 10 April 2014 20:09, Frederic Weisbecker fweis...@gmail.com wrote:
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 9f8af69..1e2d6b7
On 11 April 2014 20:48, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Apr 11, 2014 at 04:53:35PM +0200, Frederic Weisbecker wrote:
I think there's assumptions that tick runs on the local cpu;
Yes, many function behave that way, i.e. with smp_processor_id() as
CPU.
also what
are you
On Wed, Apr 09, 2014 at 04:19:44PM +0530, Viresh Kumar wrote:
> On 9 April 2014 16:03, Viresh Kumar wrote:
> > Hi Frederic,
> >
> > File: kernel/time/tick-sched.c
> > Function: tick_nohz_full_stop_tick()
> >
> > We are doing this:
> >
> > if (!tick_nohz_full_cpu(cpu) || is_idle_task(current))
> >
On Wed, Apr 09, 2014 at 04:19:44PM +0530, Viresh Kumar wrote:
On 9 April 2014 16:03, Viresh Kumar viresh.ku...@linaro.org wrote:
Hi Frederic,
File: kernel/time/tick-sched.c
Function: tick_nohz_full_stop_tick()
We are doing this:
if (!tick_nohz_full_cpu(cpu) ||
On 9 April 2014 16:03, Viresh Kumar wrote:
> Hi Frederic,
>
> File: kernel/time/tick-sched.c
> Function: tick_nohz_full_stop_tick()
>
> We are doing this:
>
> if (!tick_nohz_full_cpu(cpu) || is_idle_task(current))
> return;
>
> Which means: if a FULL_NO_HZ cpu is running idle task
Hi Frederic,
File: kernel/time/tick-sched.c
Function: tick_nohz_full_stop_tick()
We are doing this:
if (!tick_nohz_full_cpu(cpu) || is_idle_task(current))
return;
Which means: if a FULL_NO_HZ cpu is running idle task currently,
don't stop its tick..
I couldn't understand why. Can you
Hi Frederic,
File: kernel/time/tick-sched.c
Function: tick_nohz_full_stop_tick()
We are doing this:
if (!tick_nohz_full_cpu(cpu) || is_idle_task(current))
return;
Which means: if a FULL_NO_HZ cpu is running idle task currently,
don't stop its tick..
I couldn't understand why. Can you
On 9 April 2014 16:03, Viresh Kumar viresh.ku...@linaro.org wrote:
Hi Frederic,
File: kernel/time/tick-sched.c
Function: tick_nohz_full_stop_tick()
We are doing this:
if (!tick_nohz_full_cpu(cpu) || is_idle_task(current))
return;
Which means: if a FULL_NO_HZ cpu is running idle
44 matches
Mail list logo
