Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"David S.Miller" <davem@davemloft.net>,
	Ingo Molnar <mingo@kernel.org>,
	Chandramouli Narayanan <mouli@linux.intel.com>,
	Vinodh Gopal <vinodh.gopal@intel.com>,
	James Guilford <james.guilford@intel.com>,
	Wajdi Feghali <wajdi.k.feghali@intel.com>,
	Jussi Kivilinna <jussi.kivilinna@iki.fi>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu
Date: Tue, 15 Jul 2014 14:59:33 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1407151452370.24854@nanos> (raw)
In-Reply-To: <20140715120728.GR3588@twins.programming.kicks-ass.net>

On Tue, 15 Jul 2014, Peter Zijlstra wrote:

> On Tue, Jul 15, 2014 at 11:50:45AM +0200, Peter Zijlstra wrote:
> > So you already have an idle notifier (which is x86 only, we should fix
> > that I suppose), and you then double check there really isn't anything
> > else running.
> 
> Note that we've already done a large part of the expense of going idle
> by the time we call that idle notifier -- in specific, we've
> reprogrammed the clock to stop the tick.
> 
> Its really wasteful to then generate work again, which means we have to
> again reprogram the clock etc.

Doing anything which is not related to idle itself in the idle
notifier is just plain wrong.

If that stuff wants to utilize idle slots, we really need to come up
with a generic and general solution. Otherwise we'll grow those warts
all over the architecture space, with slightly different ways of
wreckaging the world an some more.

This whole attidute of people thinking that they need their own
specialized scheduling around the real scheduler is a PITA. All this
stuff is just damanging any sensible approach of power saving, load
balancing, etc.

What we really want is infrastructure, which allows the scheduler to
actively query the async work situation and based on the results
actively decide when to process it and where.

Thanks,

	tglx

  reply	other threads:[~2014-07-15 13:00 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1405074379.git.tim.c.chen@linux.intel.com>
2014-07-11 20:32 ` [PATCH v4 0/7] crypto: SHA1 multibuffer implementation Tim Chen
2014-07-11 20:32 ` [PATCH v4 1/7] crypto: SHA1 multibuffer crypto hash infrastructure Tim Chen
2014-07-11 20:32 ` [PATCH v4 2/7] crypto: SHA1 multibuffer algorithm data structures Tim Chen
2014-07-11 20:32 ` [PATCH v4 3/7] crypto: SHA1 multibuffer submit and flush routines for AVX2 Tim Chen
2014-07-11 20:32 ` [PATCH v4 4/7] crypto: SHA1 multibuffer crypto computation (x8 AVX2) Tim Chen
2014-07-11 20:33 ` [PATCH v4 5/7] crypto: SHA1 multibuffer scheduler Tim Chen
2014-07-11 20:33 ` [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu Tim Chen
2014-07-12  9:25   ` Kirill Tkhai
2014-07-14 17:51     ` Tim Chen
2014-07-12 14:21   ` Tadeusz Struk
2014-07-14 23:51     ` Tim Chen
2014-07-14 10:16   ` Peter Zijlstra
2014-07-14 16:10     ` Tim Chen
2014-07-14 16:14       ` Peter Zijlstra
2014-07-14 17:05         ` Tim Chen
2014-07-14 18:17           ` Peter Zijlstra
2014-07-14 19:08             ` Tim Chen
2014-07-14 19:15               ` Peter Zijlstra
2014-07-14 19:50                 ` Tim Chen
2014-07-15  9:50                   ` Peter Zijlstra
2014-07-15 12:07                     ` Peter Zijlstra
2014-07-15 12:59                       ` Thomas Gleixner [this message]
2014-07-15 14:45                         ` Mike Galbraith
2014-07-15 14:53                           ` Peter Zijlstra
2014-07-15 18:06                             ` Mike Galbraith
2014-07-15 19:03                               ` Peter Zijlstra
2014-07-15 19:24                                 ` Mike Galbraith
2014-07-15 18:41                         ` Tim Chen
2014-07-15 20:46                           ` Thomas Gleixner
2014-07-15 18:40                       ` Tim Chen
2014-07-15 18:40                     ` Tim Chen
2014-07-15 13:36                 ` Peter Zijlstra
2014-07-15 15:21                   ` Tejun Heo
2014-07-15 16:37                     ` Peter Zijlstra
2014-07-11 20:33 ` [PATCH v4 7/7] crypto: SHA1 multibuffer - flush the jobs early if cpu becomes idle Tim Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1407151452370.24854@nanos \
    --to=tglx@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=james.guilford@intel.com \
    --cc=jussi.kivilinna@iki.fi \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mouli@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vinodh.gopal@intel.com \
    --cc=wajdi.k.feghali@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox