All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Jeroen Van den Keybus <jeroen.vandenkeybus@domain.hid>
Cc: Xenomai-core@domain.hid
Subject: Re: [Xenomai-core] Long execution time inside __ipipe_unstall_iret_root()
Date: Mon, 12 Nov 2007 19:27:16 +0100	[thread overview]
Message-ID: <47389B04.7040700@domain.hid> (raw)
In-Reply-To: <fd6a47a90711121010k2fa1f393u10f3692f2a3b4bd7@domain.hid>

Jeroen Van den Keybus wrote:
>> Ouch, this shouldn't be allowed in user space! WBINVD is a privileged
>> instruction. Do we leak privileges to user land??? Please check if your
>> execution mode (privilege ring) is correct there.
> 
> 
> No, I rather meant a kernel-mode program that was controlled from the user
> space. Sorry for upsetting you.

Puh... fine, the world is round again. :)

> 
> But indeed, wbinvd is devastating if you can execute it, causing
>> typically around 300 us latencies, at worst even milliseconds
>> (cache-size and state dependent)!
> 
> 
> If I recall correctly, some of the Linux AGP GART drivers use(d?) it.

Yep, some only require this during setup (while MTRR reconfig e.g.),
others also use it during runtime of X - making your graphical system a
real-time killer.

> 
> This raises another interesting question: to what extent is the x86 actually
> a viable and dependable realtime platform, with its SMI's and highly
> uncontrollable caching architecture ? How would VT-based solutions compare ?

No surprise: x86 is a real-time minefield. Actually, I have been told
that PCI Express also requires cache flushes before starting DMA
transactions, but I haven't checked this yet.

Regarding fun with virtualisation over RT:

http://thread.gmane.org/gmane.comp.emulators.kvm.devel/8520/focus=8540
(There are even more threads about this, and some light at the end of
this tunnel, also for Intel. Check the archive.)

This reminds me that I still need to post my experimental kvm-over-ipipe
patch for VMX (yet Intel only, no AMD at hand :( ).

> (BTW Intel should really have implemented a feature to use parts of the
> cache as SRAM.)

Ack.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux


      reply	other threads:[~2007-11-12 18:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-12 15:39 [Xenomai-core] Long execution time inside __ipipe_unstall_iret_root() Jeroen Van den Keybus
2007-11-12 16:47 ` Jan Kiszka
2007-11-12 17:11   ` Jeroen Van den Keybus
2007-11-12 17:25     ` Jan Kiszka
     [not found]       ` <fd6a47a90711120936m6c8eb691na49fae868b803470@domain.hid>
2007-11-12 17:58         ` Jan Kiszka
2007-11-12 18:10           ` Jeroen Van den Keybus
2007-11-12 18:27             ` Jan Kiszka [this message]

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=47389B04.7040700@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=Xenomai-core@domain.hid \
    --cc=jeroen.vandenkeybus@domain.hid \
    /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.