From: Johannes Berg <johannes@sipsolutions.net>
To: Benjamin Beichler <benjamin.beichler@uni-rostock.de>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: linux-um@lists.infradead.org
Subject: Re: [PATCH RFC 01/11] um: Make UBD requests synchronous in TT ext/infcpu mode
Date: Mon, 06 Nov 2023 21:24:39 +0100 [thread overview]
Message-ID: <84cd091dc90cf4102f84778f6b8ab724212152cc.camel@sipsolutions.net> (raw)
In-Reply-To: <20231103-bb-timetravel-patches-v1-1-e2c68efcf664@uni-rostock.de>
On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote:
> The UBD driver employs multiple threads to enhance block device accesses
> in userspace. These threads communicate via pipes and are triggered by
> interrupts that utilize the SIGIO handler.
>
> However, in TT mode, both inf-cpu and external modes, this asynchronous,
> multithreaded request processing lead to issues where requests are not
> processed. This occurs because there is no dedicated time travel handler
> for the UBD interrupt.
>
> Since asynchronous, multithreaded request processing does not provide
> substantial benefits in time travel mode and may even introduce
> additional overhead (as multiple threads are scheduled sequentially to
> execute requests in TT mode with infinite CPU power), this patch
> switches to synchronous request processing directly within the
> submit_request call for the respective TT modes.
This makes perfect sense. We mostly use hostfs, but recently did the
exact same thing there.
> +#ifdef CONFIG_UML_TIME_TRAVEL_SUPPORT
> + /* do not initialize asynchronous io-thread and corresponding irq
> + * in inf-cpu or ext time travel, as we need synchronous io logic
> + */
> +
> + if (time_travel_mode == TT_MODE_INFCPU ||
> + time_travel_mode == TT_MODE_EXTERNAL)
Maybe we should finally refactor these checks though ... :)
And you don't need the ifdef, because time_travel_mode is defined to
TT_MODE_OFF without CONFIG_UML_TIME_TRAVEL_SUPPORT, and then this just
gets optimised out.
> static int ubd_submit_request(struct ubd *dev, struct request *req)
> {
> + int i;
> int segs = 0;
> struct io_thread_req *io_req;
> int ret;
> @@ -1334,6 +1354,17 @@ static int ubd_submit_request(struct ubd *dev, struct request *req)
> if (segs)
> ubd_map_req(dev, io_req, req);
>
> +#ifdef CONFIG_UML_TIME_TRAVEL_SUPPORT
> + //do the request sychronous (bypass io_thread and ubd_handler)
> + if (time_travel_mode == TT_MODE_INFCPU ||
> + time_travel_mode == TT_MODE_EXTERNAL) {
> + for (i = 0; !io_req->error && i < io_req->desc_cnt; i++)
> + do_io(io_req, &io_req->io_desc[i]);
> + finalize_request(io_req);
> + return 0;
> + }
> +#endif
>
Same here, and in fact with the ifdef you'd get an unused variable
warning, but anyway you could move that into the block (or even into the
for now that we require C99!)
johannes
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2023-11-06 20:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 16:41 [PATCH RFC 00/11] Several Time Travel Mode Enhancements Benjamin Beichler
2023-11-03 16:41 ` [PATCH RFC 01/11] um: Make UBD requests synchronous in TT ext/infcpu mode Benjamin Beichler
2023-11-06 20:24 ` Johannes Berg [this message]
2023-11-03 16:41 ` [PATCH RFC 02/11] um: add a simple time_travel_handler implementation Benjamin Beichler
2023-11-03 16:41 ` [PATCH RFC 03/11] um: Use a simple time travel handler for line interrupts Benjamin Beichler
2023-11-06 20:26 ` Johannes Berg
2023-11-10 16:53 ` Benjamin Beichler
2023-11-10 17:16 ` Johannes Berg
2023-11-13 11:46 ` Benjamin Beichler
2023-11-13 21:22 ` Johannes Berg
2023-11-13 21:57 ` Johannes Berg
2023-11-20 13:42 ` Benjamin Beichler
2023-11-24 14:53 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 04/11] um: Handle UM_TIMETRAVEL_RUN only in idle loop, signal success in ACK Benjamin Beichler
2023-11-06 20:53 ` Johannes Berg
2023-11-10 18:41 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 05/11] um: Add final request time to TT wait message Benjamin Beichler
2023-11-06 20:29 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 06/11] um: always send UM_TIMETRAVEL_REQUEST from ISRs Benjamin Beichler
2023-11-06 20:32 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 07/11] um: add TIMETRAVEL_REQUEST handler to request latest event Benjamin Beichler
2023-11-06 20:33 ` Johannes Berg
2023-11-10 16:23 ` Benjamin Beichler
2023-11-10 17:19 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 08/11] um: Protect accesses to the timetravel event list Benjamin Beichler
2023-11-06 20:37 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 09/11] um: Delay timer_read in time travel mode only after consecutive reads Benjamin Beichler
2023-11-06 20:40 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 10/11] um: Delay timer_read only in possible busy loops in TT-mode Benjamin Beichler
2023-11-06 20:51 ` Johannes Berg
2023-11-10 15:54 ` Benjamin Beichler
2023-11-10 16:39 ` Benjamin Berg
2023-11-10 17:29 ` Johannes Berg
2023-11-03 16:41 ` [PATCH RFC 11/11] um: Remove all TSC flags when using Time Travel Mode Benjamin Beichler
2023-11-03 18:45 ` Anton Ivanov
2023-11-06 20:52 ` Johannes Berg
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=84cd091dc90cf4102f84778f6b8ab724212152cc.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=anton.ivanov@cambridgegreys.com \
--cc=benjamin.beichler@uni-rostock.de \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
/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