From: Vladislav Bolkhovitin <vst@vlnb.net>
To: Fabio Checconi <fabio@gandalf.sssup.it>
Cc: linux-kernel@vger.kernel.org, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: Dynamic switching of io_context
Date: Wed, 17 Dec 2008 21:52:00 +0300 [thread overview]
Message-ID: <49494A50.3090201@vlnb.net> (raw)
In-Reply-To: <20081216082235.GD3284@gandalf.sssup.it>
Fabio Checconi, on 12/16/2008 11:22 AM wrote:
>> In SCST (http://scst.sf.net) in some cases IO can be submitted
>> asynchronously. This is possible for pass-through (i.e. using
>> scsi_execute_async()) and BLOCKIO (i.e. using direct bio interface, see
>> blockio_exec_rw() in
>> http://scst.svn.sourceforge.net/viewvc/scst/trunk/scst/src/dev_handlers/scst_vdisk.c?revision=614&view=markup)
>> backend. For them there's no need to have a per device pool of threads, one
>> or more global thread(s) can perfectly do all the work. But it is very
>> desirable for performance that all the IO is submitted in a dedicated IO
>> context for each initiator (i.e. client), which originated it. I.e.
>> commands from initiator 1 submitted in IO context IOC1, from initiator 2 -
>> IOC2, etc. Most likely, the same approach would be very useful for NFS
>> server as well.
>>
>> To achieve that it is necessary to have a possibility to switch IO
>> context of the threads on the fly. I tried to implement that (see the
>> attached patch), but hit BUG_ON(!cic->dead_key) in cic_free_func(), when
>> session for initiator with the corresponding IO context was being
>> destroyed by scst_free_tgt_dev(). At that point it was guaranteed that
>> there was no outstanding IO with this IO context.
>>
>> So, I had to go to a more defensive approach to have for each pool of
>> threads, including threads for async. IO, a dedicated IO context, which
>> is currently implemented.
>>
>> Could you advice please what was going wrong? What should I do to
>> achieve what's desired?
>
> I think the problem may be that cfq expects cfq_exit_io_context()
> to be called before the last reference to an io context is put.
> Since cfq_exit_io_context() is called during process exit, and AFAICT
> you are not calling exit_io_context() on the given ioc, cfq finds it
> in an incorrect state.
With your hint I figured out that put_io_context() isn't sufficient and
I should also call exit_io_context() instead of the latest
put_io_context(). Thanks!
> I haven't seen the rest of the code, so I may be wrong, but I suppose
> that a better approach would be to use CLONE_IO to share io contexts,
> if possible.
Unfortunately, it would be very non-optimal. As it is known, to achieve
the best performance with async. IO, it should be submitted by a limited
number of threads <= CPU count. So, the only way to submit IO from each
of, e.g. 100, clients in a dedicated per-client IO context is to
dynamically switch io_context of the current threads to io_context of
the client before IO submission.
Vlad
next prev parent reply other threads:[~2008-12-17 18:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 19:18 Dynamic switching of io_context Vladislav Bolkhovitin
[not found] ` <20081216082235.GD3284@gandalf.sssup.it>
2008-12-17 18:52 ` Vladislav Bolkhovitin [this message]
2008-12-18 13:40 ` Jens Axboe
2008-12-18 13:47 ` Vladislav Bolkhovitin
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=49494A50.3090201@vlnb.net \
--to=vst@vlnb.net \
--cc=fabio@gandalf.sssup.it \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.