From: Peter Zijlstra <peterz@infradead.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: 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: Mon, 14 Jul 2014 12:16:11 +0200 [thread overview]
Message-ID: <20140714101611.GS9918@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1405110784.2970.655.camel@schen9-DESK>
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
On Fri, Jul 11, 2014 at 01:33:04PM -0700, Tim Chen wrote:
> This function will help a thread decide if it wants to to do work
> that can be delayed, to accumulate more tasks for more efficient
> batch processing later.
>
> However, if no other tasks are running on the cpu, it can take
> advantgae of the available cpu cycles to complete the tasks
> for immediate processing to minimize delay, otherwise it will yield.
Ugh.. and ignore topology and everything else.
Yet another scheduler on top of the scheduler.
We have the padata muck, also only ever used by crypto.
We have the workqueue nonsense, used all over the place
And we have btrfs doing their own padata like muck.
And I'm sure there's at least one more out there, just because.
Why do we want yet another thing?
I'm inclined to go NAK and get people to reduce the amount of async
queueing and processing crap.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-07-14 10:16 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 [this message]
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
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=20140714101611.GS9918@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--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=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;
as well as URLs for NNTP newsgroup(s).