public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox