From: Johannes Berg <johannes@sipsolutions.net>
To: Benjamin Beichler <Benjamin.Beichler@uni-rostock.de>,
linux-um@lists.infradead.org
Subject: Re: [PATCH 1/4] um: irqs: process outstanding IRQs when unblocking signals
Date: Fri, 20 Oct 2023 14:58:00 +0200 [thread overview]
Message-ID: <7be4403e56526035e334b217c370f511060802fc.camel@sipsolutions.net> (raw)
In-Reply-To: <9768bf43-5a73-4eba-ae4b-532b952f9e04@uni-rostock.de>
On Fri, 2023-10-20 at 14:43 +0200, Benjamin Beichler wrote:
> > > Yes but you need to schedule for the interrupt, and you don't
> > > necessarily know what 'current time' is at interrupt time.
> > >
> > > So let's say you have "something" that's scheduled to run at times
> > > - 1000
> > > - 2000
> > > - 3000
> > >
> > > and free-until is 10000 or something high.
> > >
> > It can also happen without free-until, then it just depends which one of
> > the two - they're running in parallel now (linux doing time-travel
> > interrupt handling and adding the event, the other thing continuing to
> > schedule and doing the next entry) - asks the controller first.
>
> Since they happen at the same time, most discrete event simulations make
> the assumption, that the actual order of execution should not be part of
> the semantics.
>
Well, fair, but they can bounce more messages around them, and that
should change things. I don't think we've built a simulation system here
that can strictly assume this is true.
In any case, it can get worse - if he sender process actually updated
the controller to 2000 by the time the linux actually calls
time_travel_add_irq_event(), the linux event will run at 2000 instead of
1000.
All this is why we have the vhost-user extensions for ACK messages etc.
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-10-20 12:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 12:36 [PATCH 1/4] um: irqs: process outstanding IRQs when unblocking signals benjamin
2023-10-18 12:36 ` [PATCH 2/4] um: chan_user: catch EINTR when reading and writing benjamin
2023-10-18 12:36 ` [PATCH 3/4] um: chan_user: retry partial writes benjamin
2023-10-18 12:36 ` [PATCH 4/4] um: chan: use blocking IO for console output for time-travel benjamin
2023-10-20 9:15 ` [PATCH 1/4] um: irqs: process outstanding IRQs when unblocking signals Benjamin Beichler
2023-10-20 9:26 ` Anton Ivanov
2023-10-20 10:33 ` Benjamin Beichler
2023-10-20 9:59 ` Benjamin Berg
2023-10-20 10:38 ` Benjamin Beichler
2023-10-20 11:39 ` Johannes Berg
2023-10-20 12:06 ` Benjamin Beichler
2023-10-20 12:20 ` Johannes Berg
2023-10-20 12:23 ` Johannes Berg
2023-10-20 12:43 ` Benjamin Beichler
2023-10-20 12:58 ` Johannes Berg [this message]
2023-10-20 12:58 ` Benjamin Beichler
2023-10-20 13:39 ` Johannes Berg
2023-10-20 15:47 ` Benjamin Beichler
2023-10-20 15:51 ` 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=7be4403e56526035e334b217c370f511060802fc.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Benjamin.Beichler@uni-rostock.de \
--cc=linux-um@lists.infradead.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