From: Tejun Heo <tj@kernel.org>
To: Milan Broz <mbroz@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
device-mapper development <dm-devel@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [RFC PATCH 00/20] dm-crypt: parallel processing
Date: Thu, 23 Aug 2012 13:15:36 -0700 [thread overview]
Message-ID: <20120823201536.GE14962@google.com> (raw)
In-Reply-To: <5034B459.1000107@redhat.com>
Hello,
On Wed, Aug 22, 2012 at 12:28:41PM +0200, Milan Broz wrote:
> Whatever, if logic is implemented in workqueue code, others can use t as well.
> I would really prefer not to have "too smart" dmcrypt...
> (Someone mentioned btrfs on top of it with all workqueues - how it can behave nicely
> if every layer will try to implement own smart logic.)
>
> Anyway, thanks for discussion, this is exactly what was missing here :)
I've been thinking about it and am still unsure. If there are enough
use cases, we can try to manage unbound workers such that each CPU has
some standby ones, but at this point such approach seems a bit
overkill and I'm skeptical how useful a purely opportunistic approach
would be.
Another thing is that this is something which really belongs to the
scheduler. The scheduler can know better and do things like this much
better. Unfortunately, kthreads don't have mechanisms to be
discovered in terms of its optimal association (as opposed to, say,
autonuma for userland).
So... I don't know. dm-crypt probably is the most extreme use case in
kernel, so maybe going for specialized solution might not be too
crazy. Also, how much of a problem is this? Is it really worth
solving?
Thanks.
--
tejun
next prev parent reply other threads:[~2012-08-23 20:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-21 9:08 [RFC PATCH 00/20] dm-crypt: parallel processing Milan Broz
2012-08-21 9:09 ` [PATCH 01/20] dm-crypt: remove per-cpu structure Mikulas Patocka
2012-08-21 9:09 ` [PATCH 02/20] dm-crypt: use unbound workqueue for request processing Mikulas Patocka
2012-08-21 9:09 ` [PATCH 03/20] dm-crypt: remove completion restart Mikulas Patocka
2012-08-21 9:09 ` [PATCH 04/20] dm-crypt: use encryption threads Mikulas Patocka
2012-08-21 9:09 ` [PATCH 05/20] dm-crypt: Unify spinlock Mikulas Patocka
2012-08-21 9:09 ` [PATCH 06/20] dm-crypt: Introduce an option that sets the number of threads Mikulas Patocka
2012-08-21 9:09 ` [PATCH 07/20] dm-crypt: don't use write queue Mikulas Patocka
2012-08-21 9:09 ` [PATCH 08/20] dm-crypt: simplify io queue Mikulas Patocka
2012-08-21 9:09 ` [PATCH 09/20] dm-crypt: unify io_queue and crypt_queue Mikulas Patocka
2012-08-21 9:09 ` [PATCH 10/20] dm-crypt: don't allocate pages for a partial request Mikulas Patocka
2012-08-21 9:09 ` [PATCH 11/20] dm-crypt: avoid deadlock in mempools Mikulas Patocka
2012-08-21 9:09 ` [PATCH 12/20] dm-crypt: simplify cc_pending Mikulas Patocka
2012-08-21 9:09 ` [PATCH 13/20] dm-crypt merge convert_context and dm_crypt_io Mikulas Patocka
2012-08-21 9:09 ` [PATCH 14/20] dm-crypt: move error handling to crypt_convert Mikulas Patocka
2012-08-21 9:09 ` [PATCH 15/20] dm-crypt: remove io_pending field Mikulas Patocka
2012-08-21 9:09 ` [PATCH 16/20] dm-crypt: small changes Mikulas Patocka
2012-08-21 9:09 ` [PATCH 17/20] dm-crypt: move temporary values to stack Mikulas Patocka
2012-08-21 9:09 ` [PATCH 18/20] dm-crypt: offload writes to thread Mikulas Patocka
2012-08-21 9:09 ` [PATCH 19/20] dm-crypt: retain write ordering Mikulas Patocka
2012-08-21 9:09 ` [PATCH 20/20] dm-crypt: sort writes Mikulas Patocka
2012-08-21 10:57 ` Alasdair G Kergon
2012-08-21 13:39 ` Mikulas Patocka
2012-08-21 9:37 ` [RFC PATCH 00/20] dm-crypt: parallel processing Milan Broz
2012-08-21 18:23 ` Tejun Heo
2012-08-21 19:26 ` Vivek Goyal
2012-08-22 10:28 ` Milan Broz
2012-08-23 20:15 ` Tejun Heo [this message]
2012-08-21 13:32 ` Mike Snitzer
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=20120823201536.GE14962@google.com \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=mbroz@redhat.com \
--cc=vgoyal@redhat.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).