[patch] crypto,ccp: Fix RT breaking #include

2016-04-05 Thread Mike Galbraith

Direct include of rwlock_types.h breaks RT, use spinlock_types.h instead.

Fixes: 553d2374db0b crypto: ccp - Support for multiple CCPs
Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com>
---
 drivers/crypto/ccp/ccp-dev.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu

2014-07-15 Thread Mike Galbraith
On Tue, 2014-07-15 at 21:03 +0200, Peter Zijlstra wrote: 
 On Tue, Jul 15, 2014 at 08:06:55PM +0200, Mike Galbraith wrote:
  On Tue, 2014-07-15 at 16:53 +0200, Peter Zijlstra wrote: 
   On Tue, Jul 15, 2014 at 04:45:25PM +0200, Mike Galbraith wrote:

3.0.101-default3.753363 usecs/loop -- avg 3.770737 530.4 KHz   
1.000
3.14.10-default4.145348 usecs/loop -- avg 4.139987 483.1 KHz
.910 1.000
3.15.4-default 4.355594 usecs/loop -- avg 4.351961 459.6 KHz
.866  .9511.000
3.16.0-default 4.537279 usecs/loop -- avg 4.543532 440.2 KHz
.829  .911 .957

3.0.101-smp3.692377 usecs/loop -- avg 3.690774 541.9 KHz   
1.000
3.14.10-smp4.010009 usecs/loop -- avg 4.009019 498.9 KHz
.920
3.15.4-smp 3.882398 usecs/loop -- avg 3.884095 514.9 KHz
.950
3.16.0-master  4.061003 usecs/loop -- avg 4.058244 492.8 KHz
.909
   
   Urgh,.. I need to go fix that :/
  
  I'm poking about.  It's not just one thing 'course, just lots of change
  adding up to less than wonderful.  Idle changes are costing some, for
  obese config, avg goop.  The select_next_task() reorganization appears
  to be costing, but eyeballing, I can see no excuse for that at all.
 
 How is the idle stuff costing, cpu-affine pipe-test should pretty much
 peg a cpu at 100%, right? Or did I mis-understand and are you running a
 loose pipe-test?

Exactly, I'm measuring the cost of popping in and out of idle while
trying to reclaim overlap (which doesn't exist in pipe-test case).

-Mike

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html