Re: [PATCH v5 22/27] MDSv5 24

From: Thomas Gleixner <tglx@linutronix.de>
To: speck@linutronix.de
Subject: Re: [PATCH v5 22/27] MDSv5 24
Date: Tue, 22 Jan 2019 19:56:20 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.21.1901221858480.1628@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20190122175614.GV6118@tassilo.jf.intel.com>

On Tue, 22 Jan 2019, speck for Andi Kleen wrote:
> On Tue, Jan 22, 2019 at 05:09:05PM +0100, speck for Thomas Gleixner wrote:
> At least in my limited testing the patch doesn't cause that
> actually, even though it may be counterintuitive.
> 
> See the numbers for Chrome for example in the last EBPF patch. That's
> a complex workload with many context switches, and it gets
> a clear roughly every third syscall

I'd rather see numbers with the switch_to hackery actually using
thread_info::flags.

> So this only leaves some latency sensitive workloads,
> which cannot mitigate interrupts, but the interrupt handlers for those can
> be fixed over time based on profiling results. Overall I suspect it
> will be only a small subset of the total number of drivers.

Ah, and who is going to that analysis and who is going to fix that?

> Of course that really needs to be validated with more testing.
> 
> > The only sane way IMO is to have mds=cond just handle context switching and
> > then have proper
> 
> It's only sane if you have a good way to find and maintain all these places.
> 
> So far nobody has proposed a scalable way to do that. I personally
> don't know how to do it. 

If you look at the interrupts which actually are related to data which
might be sensible, then you'll notice that most of them do absolutely
nothing except scheduling softirqs, worker threads etc. The actual data
handling happens there. If it's a worker thread, then the context switch
covers it.

Softirqs are a different story, but most of that is probably networking and
perhaps tasklets.

Just for the numbers:

   hrtimer_init():    170 instances
   timer_setup():    1129 instances
   DEFINE_TIMER():     46 instances
   tasklet_init():    361 instances
   request.*irq():   1462 instances

Now just for request_irq. Removing all threaded interrupt requests and only
looking at drivers reduces the number to 1118. Just going through the
matching files and removing the obvious non x86 and non interesting drivers
which obviously do not touch sensititve data, thermal, watchdog and lots of
others, reduces the number to less than 500. Remove 185 instances of
drivers/net/ethernet which all do merily napi_schedule() then it shrinks
very fast to something which can be easily managed to look at.

Thanks,

	tglx