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 06/11] um: always send UM_TIMETRAVEL_REQUEST from ISRs
Date: Mon, 06 Nov 2023 21:32:50 +0100 [thread overview]
Message-ID: <c42b1a738da2b335f84266978bb3bf0aa6ccb78e.camel@sipsolutions.net> (raw)
In-Reply-To: <20231103-bb-timetravel-patches-v1-6-e2c68efcf664@uni-rostock.de>
On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote:
> The number of UM_TIMETRAVEL_REQUEST msgs is tried to reduced, if they
> are redundant via the time_travel_ext_prev_request_valid flag.
>
This ... doesn't parse so well. I think I get what you're trying to say,
but it's a bit awkward?
Maybe say "The code attempts to reduce the number of ... messages if
they are redundant. This is achieved with the ... flag." or something
like that?
At least that's what I think what you're trying to say :)
> This can
> create a race condition, when an interrupt happens and the idle loop
> wants to wait.
>
> This means, sometimes the UM_TIMETRAVEL_REQUEST are sent(when the idle
> loop already started waiting) and sometimes not, which makes it harder
> to implement the other end of the scheduler.
Not sure I get that though, why does it matter? Just keep track of the
last request?
Do you have some kind of (calendar) logs that would show the different
message behaviour?
FWIW, we've also got work pending for a while now that we should submit
that implements scheduling via shared memory for the most part, so that
all these REQUEST and time update messages just go away _entirely_,
which helps a lot for performance too.
> +++ b/arch/um/kernel/time.c
> @@ -446,6 +446,7 @@ void time_travel_add_irq_event(struct time_travel_event *e)
> BUG_ON(time_travel_mode != TT_MODE_EXTERNAL);
>
> time_travel_ext_get_time();
> + time_travel_ext_prev_request_valid = false;
>
At the very least I think there should be a comment here, but I'm not
really convinced yet why this makes sense :)
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:33 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
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 [this message]
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=c42b1a738da2b335f84266978bb3bf0aa6ccb78e.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