From: Jens Axboe <jens.axboe@oracle.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: akpm@osdl.org, jdike@addtoit.com, linux-kernel@vger.kernel.org,
user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup
Date: Mon, 30 Oct 2006 09:26:48 +0100 [thread overview]
Message-ID: <20061030082643.GM4563@kernel.dk> (raw)
In-Reply-To: <200610292023.12980.blaisorblade@yahoo.it>
On Sun, Oct 29 2006, Blaisorblade wrote:
> Add some comments about requirements for ubd_io_lock and expand its use.
>
> When an irq signals that the "controller" (i.e. another thread on the host,
> which does the actual requests and is the only one blocked on I/O on the
> host) has done some work, we call again the request function ourselves
> (do_ubd_request).
>
> We now do that with ubd_io_lock held - that's useful to protect against
> concurrent calls to elv_next_request and so on.
Not only useful, required, as I think I complained about a year or more
ago :-)
> XXX: Maybe we shouldn't call at all the request function. Input needed on
> this. Are we supposed to plug and unplug the queue? That code "indirectly"
> does that by setting a flag, called do_ubd, which makes the request function
> return (it's a residual of 2.4 block layer interface).
Sometimes you need to. I'd probably just remove the do_ubd check and
always recall the request function when handling completions, it's
easier and safe.
--
Jens Axboe
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jens.axboe@oracle.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: akpm@osdl.org, jdike@addtoit.com,
user-mode-linux-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup
Date: Mon, 30 Oct 2006 09:26:48 +0100 [thread overview]
Message-ID: <20061030082643.GM4563@kernel.dk> (raw)
In-Reply-To: <200610292023.12980.blaisorblade@yahoo.it>
On Sun, Oct 29 2006, Blaisorblade wrote:
> Add some comments about requirements for ubd_io_lock and expand its use.
>
> When an irq signals that the "controller" (i.e. another thread on the host,
> which does the actual requests and is the only one blocked on I/O on the
> host) has done some work, we call again the request function ourselves
> (do_ubd_request).
>
> We now do that with ubd_io_lock held - that's useful to protect against
> concurrent calls to elv_next_request and so on.
Not only useful, required, as I think I complained about a year or more
ago :-)
> XXX: Maybe we shouldn't call at all the request function. Input needed on
> this. Are we supposed to plug and unplug the queue? That code "indirectly"
> does that by setting a flag, called do_ubd, which makes the request function
> return (it's a residual of 2.4 block layer interface).
Sometimes you need to. I'd probably just remove the do_ubd check and
always recall the request function when handling completions, it's
easier and safe.
--
Jens Axboe
next parent reply other threads:[~2006-10-30 8:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200610292023.12980.blaisorblade@yahoo.it>
2006-10-30 8:26 ` Jens Axboe [this message]
2006-10-30 8:26 ` [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup Jens Axboe
2006-10-29 19:17 [uml-devel] [PATCH 00/11] UBD driver little cleanups for 2.6.19 Paolo 'Blaisorblade' Giarrusso
2006-10-29 19:20 ` [uml-devel] [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup Paolo 'Blaisorblade' Giarrusso
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=20061030082643.GM4563@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=akpm@osdl.org \
--cc=blaisorblade@yahoo.it \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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.