On 8/3/2015 1:39 PM, Frederic Weisbecker wrote:
On Mon, Aug 03, 2015 at 07:12:43PM +0200, Peter Zijlstra wrote:
On Fri, Jul 31, 2015 at 04:49:55PM +0200, Frederic Weisbecker wrote:
Instead of doing a per signal dependency, I'm going to use a per task
one.
Urgh, does this mean you'll keep the h
On Mon, Aug 03, 2015 at 07:39:37PM +0200, Frederic Weisbecker wrote:
> On Mon, Aug 03, 2015 at 07:12:43PM +0200, Peter Zijlstra wrote:
> > On Fri, Jul 31, 2015 at 04:49:55PM +0200, Frederic Weisbecker wrote:
> > > Instead of doing a per signal dependency, I'm going to use a per task
> > > one.
> >
On Mon, Aug 03, 2015 at 11:59:07AM -0400, Chris Metcalf wrote:
> On 07/31/2015 10:49 AM, Frederic Weisbecker wrote:
> >Instead of doing a per signal dependency, I'm going to use a per task
> >one. Which means that if a per-process timer is enqueued, every thread
> >of that process will have the tic
On Mon, Aug 03, 2015 at 07:12:43PM +0200, Peter Zijlstra wrote:
> On Fri, Jul 31, 2015 at 04:49:55PM +0200, Frederic Weisbecker wrote:
> > Instead of doing a per signal dependency, I'm going to use a per task
> > one.
>
> Urgh, does this mean you'll keep the horrid tick_nohz_task_switch()
> thing?
On Fri, Jul 31, 2015 at 04:49:55PM +0200, Frederic Weisbecker wrote:
> Instead of doing a per signal dependency, I'm going to use a per task
> one.
Urgh, does this mean you'll keep the horrid tick_nohz_task_switch()
thing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 07/31/2015 10:49 AM, Frederic Weisbecker wrote:
Instead of doing a per signal dependency, I'm going to use a per task
one. Which means that if a per-process timer is enqueued, every thread
of that process will have the tick dependency. But if the timer is
enqueued to a single thread, only the
On Thu, Jul 30, 2015 at 03:52:54PM -0400, Chris Metcalf wrote:
> On 07/30/2015 03:45 PM, Frederic Weisbecker wrote:
> >
> You mentioned needing two fields, for task and for process, but in
> fact let's just add the one field to the one thing that needs it and
> not worry about additiona
On 07/30/2015 03:45 PM, Frederic Weisbecker wrote:
You mentioned needing two fields, for task and for process, but in
fact let's just add the one field to the one thing that needs it and
not worry about additional possible future needs. And note that it's
the task_struct->signal where we need
On Thu, Jul 30, 2015 at 03:35:06PM -0400, Chris Metcalf wrote:
> On 07/29/2015 08:44 PM, Frederic Weisbecker wrote:
> >I see. But note that installing a posix cpu timer ends up triggering an
> >IPI to all nohz full CPUs. That's how nohz full has always behaved.
> >So users running posix timers on n
On 07/29/2015 08:44 PM, Frederic Weisbecker wrote:
On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote:
On 07/29/2015 09:23 AM, Frederic Weisbecker wrote:
At a higher level, is the posix-cpu-timers code here really providing the
right semantics? It seems like before, the code was che
On Thu, Jul 30, 2015 at 10:31:47AM -0400, Luiz Capitulino wrote:
> On Thu, 30 Jul 2015 02:44:45 +0200
> Frederic Weisbecker wrote:
> > On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote:
> > > I really worry about this! The vision EZchip offers our customers is
> > > that they can run
On Thu, 30 Jul 2015 02:44:45 +0200
Frederic Weisbecker wrote:
>
> On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote:
> > On 07/29/2015 09:23 AM, Frederic Weisbecker wrote:
> > >>At a higher level, is the posix-cpu-timers code here really providing the
> > >>>right semantics? It seems
On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote:
> On 07/29/2015 09:23 AM, Frederic Weisbecker wrote:
> >>At a higher level, is the posix-cpu-timers code here really providing the
> >>>right semantics? It seems like before, the code was checking a struct
> >>>task-specific state, and
On 07/29/2015 09:23 AM, Frederic Weisbecker wrote:
At a higher level, is the posix-cpu-timers code here really providing the
>right semantics? It seems like before, the code was checking a struct
>task-specific state, and now you are setting a global state such that if ANY
>task anywhere in the s
On Fri, Jul 24, 2015 at 12:57:24PM -0400, Chris Metcalf wrote:
> On 07/23/2015 12:42 PM, Frederic Weisbecker wrote:
> >+static void cpu_timer_list_dequeue(struct cpu_timer_list *t)
> >+{
> >+if (!list_empty(&t->entry))
> >+cpu_timer_dec_tick_dependency();
> >+list_del_init(&t->e
On 07/23/2015 12:42 PM, Frederic Weisbecker wrote:
+static void cpu_timer_list_dequeue(struct cpu_timer_list *t)
+{
+ if (!list_empty(&t->entry))
+ cpu_timer_dec_tick_dependency();
+ list_del_init(&t->entry);
+}
Is the list_empty() test necessary? It wasn't in the orig
Instead of providing asynchronous checks for the nohz subsystem to verify
posix cpu timers tick dependency, migrate the latter to the new mask.
In order to keep track of the running timers and expose the tick
dependency accordingly, we must probe the timers queuing and dequeuing
on threads and pro
17 matches
Mail list logo
