Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1516324 > unrolled thread

Re: task isolation discussion at Linux Plumbers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: task isolation discussion at Linux Plumbers Thomas Gleixner <tglx@linutronix.de> - 2016-11-07 18:00 +0100
    Re: task isolation discussion at Linux Plumbers Thomas Gleixner <tglx@linutronix.de> - 2016-11-07 19:50 +0100
      Re: task isolation discussion at Linux Plumbers Rik van Riel <riel@redhat.com> - 2016-11-07 20:20 +0100
      Re: task isolation discussion at Linux Plumbers Will Deacon <will.deacon@arm.com> - 2016-11-07 20:20 +0100
      Re: task isolation discussion at Linux Plumbers Rik van Riel <riel@redhat.com> - 2016-11-07 20:30 +0100

#1516324 — Re: task isolation discussion at Linux Plumbers

On Sat, 5 Nov 2016, Chris Metcalf wrote:
> == Remote statistics ==
> 
> We discussed the possibility of remote statistics gathering, i.e. load
> average etc.  The idea would be that we could have housekeeping
> core(s) periodically iterate over the nohz cores to load their rq
> remotely and do update_current etc.  Presumably it should be possible
> for a single housekeeping core to handle doing this for all the
> nohz_full cores, as we only need to do it quite infrequently.
> 
> Thomas suggested that this might be the last remaining thing that
> needed to be done to allow disabling the current behavior of falling
> back to a 1 Hz clock in nohz_full.
> 
> I believe Thomas said he had a patch to do this already.

No, Riek was working on that.

> == Remote LRU cache drain ==
> 
> One of the issues with task isolation currently is that the LRU cache
> drain must be done prior to entering userspace, but it requires
> interrupts enabled and thus can't be done atomically.  My previous
> patch series have handled this by checking with interrupts disabled,
> but then looping around with interrupts enabled to try to drain the
> LRU pagevecs.  Experimentally this works, but it's not provable that
> it terminates, which is worrisome.  Andy suggested adding a percpu
> flag to disable creation of deferred work like LRU cache pages.
> 
> Thomas suggested using an RT "local lock" to guard the LRU cache
> flush; he is planning on bringing the concept to mainline in any case.
> However, after some discussion we converged on simply using a spinlock
> to guard the appropriate resources.  As a result, the
> lru_add_drain_all() code that currently queues work on each remote cpu
> to drain it, can instead simply acquire the lock and drain it remotely.
> This means that a task isolation task no longer needs to worry about
> being interrupted by SMP function call IPIs, so we don't have to deal
> with this in the task isolation framework any more.
> 
> I don't recall anyone else volunteering to tackle this, so I will plan
> to look at it.  The patch to do that should be orthogonal to the
> revised task isolation patch series.

I offered to clean up the patch from RT. I'll do that in the next days.
 
> == Missing oneshot_stopped callbacks ==
> 
> I raised the issue that various clock_event_device sources don't
> always support oneshot_stopped, which can cause an additional
> final interrupt to occur after the timer infrastructure believes the
> interrupt has been stopped.  I have patches to fix this for tile and
> arm64 in my patch series; Thomas volunteered to look at adding
> equivalent support for x86.

Right.

Thanks,

	tglx

[toc] | [next] | [standalone]

#1516465

On Mon, 7 Nov 2016, Thomas Gleixner wrote:
> > == Missing oneshot_stopped callbacks ==
> > 
> > I raised the issue that various clock_event_device sources don't
> > always support oneshot_stopped, which can cause an additional
> > final interrupt to occur after the timer infrastructure believes the
> > interrupt has been stopped.  I have patches to fix this for tile and
> > arm64 in my patch series; Thomas volunteered to look at adding
> > equivalent support for x86.
> 
> Right.

Untested patch below should fix that.

Thanks,

	tglx

8<---------------
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -530,18 +530,20 @@ static void lapic_timer_broadcast(const
  * The local apic timer can be used for any function which is CPU local.
  */
 static struct clock_event_device lapic_clockevent = {
-	.name			= "lapic",
-	.features		= CLOCK_EVT_FEAT_PERIODIC |
-				  CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP
-				  | CLOCK_EVT_FEAT_DUMMY,
-	.shift			= 32,
-	.set_state_shutdown	= lapic_timer_shutdown,
-	.set_state_periodic	= lapic_timer_set_periodic,
-	.set_state_oneshot	= lapic_timer_set_oneshot,
-	.set_next_event		= lapic_next_event,
-	.broadcast		= lapic_timer_broadcast,
-	.rating			= 100,
-	.irq			= -1,
+	.name				= "lapic",
+	.features			= CLOCK_EVT_FEAT_PERIODIC |
+					  CLOCK_EVT_FEAT_ONESHOT |
+					  CLOCK_EVT_FEAT_C3STOP |
+					  CLOCK_EVT_FEAT_DUMMY,
+	.shift				= 32,
+	.set_state_shutdown		= lapic_timer_shutdown,
+	.set_state_periodic		= lapic_timer_set_periodic,
+	.set_state_oneshot		= lapic_timer_set_oneshot,
+	.set_state_oneshot_stopped	= lapic_timer_shutdown,
+	.set_next_event			= lapic_next_event,
+	.broadcast			= lapic_timer_broadcast,
+	.rating				= 100,
+	.irq				= -1,
 };
 static DEFINE_PER_CPU(struct clock_event_device, lapic_events);
 

[toc] | [prev] | [next] | [standalone]

#1516518

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2016-11-07 at 19:16 +0000, Will Deacon wrote:
> On Mon, Nov 07, 2016 at 02:12:13PM -0500, Rik van Riel wrote:
> > 
> > On Mon, 2016-11-07 at 19:36 +0100, Thomas Gleixner wrote:
> > > 
> > > On Mon, 7 Nov 2016, Thomas Gleixner wrote:
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > == Missing oneshot_stopped callbacks ==
> > > > > 
> > > > > I raised the issue that various clock_event_device sources
> > > > > don't
> > > > > always support oneshot_stopped, which can cause an additional
> > > > > final interrupt to occur after the timer infrastructure
> > > > > believes
> > > > > the
> > > > > interrupt has been stopped.  I have patches to fix this for
> > > > > tile
> > > > > and
> > > > > arm64 in my patch series; Thomas volunteered to look at
> > > > > adding
> > > > > equivalent support for x86.
> > > > 
> > > > Right.
> > > 
> > > Untested patch below should fix that.
> > >  
> > 
> > That whitespace cleanup looks awesome, but I am not
> > optimistic about its chances to bring about functional
> > change.
> > 
> > What am I overlooking?
> 
> It hooks up .set_state_oneshot_stopped?

Gah, indeed. Never mind :)

-- 
All Rights Reversed.

[toc] | [prev] | [next] | [standalone]

#1516521

On Mon, Nov 07, 2016 at 02:12:13PM -0500, Rik van Riel wrote:
> On Mon, 2016-11-07 at 19:36 +0100, Thomas Gleixner wrote:
> > On Mon, 7 Nov 2016, Thomas Gleixner wrote:
> > > 
> > > > 
> > > > == Missing oneshot_stopped callbacks ==
> > > > 
> > > > I raised the issue that various clock_event_device sources don't
> > > > always support oneshot_stopped, which can cause an additional
> > > > final interrupt to occur after the timer infrastructure believes
> > > > the
> > > > interrupt has been stopped.  I have patches to fix this for tile
> > > > and
> > > > arm64 in my patch series; Thomas volunteered to look at adding
> > > > equivalent support for x86.
> > > 
> > > Right.
> > 
> > Untested patch below should fix that.
> > 
> 
> That whitespace cleanup looks awesome, but I am not
> optimistic about its chances to bring about functional
> change.
> 
> What am I overlooking?

It hooks up .set_state_oneshot_stopped?

Will

[toc] | [prev] | [next] | [standalone]

#1516528

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2016-11-07 at 19:36 +0100, Thomas Gleixner wrote:
> On Mon, 7 Nov 2016, Thomas Gleixner wrote:
> > 
> > > 
> > > == Missing oneshot_stopped callbacks ==
> > > 
> > > I raised the issue that various clock_event_device sources don't
> > > always support oneshot_stopped, which can cause an additional
> > > final interrupt to occur after the timer infrastructure believes
> > > the
> > > interrupt has been stopped.  I have patches to fix this for tile
> > > and
> > > arm64 in my patch series; Thomas volunteered to look at adding
> > > equivalent support for x86.
> > 
> > Right.
> 
> Untested patch below should fix that.
> 

That whitespace cleanup looks awesome, but I am not
optimistic about its chances to bring about functional
change.

What am I overlooking?

-- 
All Rights Reversed.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web