All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Michael Gagnon <mgagnon1@gmu.edu>
Subject: Re: [Qemu-devel] Time complexity for self-modifying code
Date: Thu, 8 Feb 2007 20:37:36 +0000	[thread overview]
Message-ID: <200702082037.36905.paul@codesourcery.com> (raw)
In-Reply-To: <45CB81B5.9080405@gmu.edu>

On Thursday 08 February 2007 20:01, Michael Gagnon wrote:
> Hello.  I'm a student at George Mason University and I had a question
> regarding the time complexity of QEMU's algorithm for dealing with
> self-modifying code.
>
>  From looking at the QEMU Internals documentation
> (http://fabrice.bellard.free.fr/qemu/qemu-tech.html), it seems that
> QEMU's method for handling self-modifying code might have different
> algorithmic efficiency classes for it's average case and worst case.  As
> in, on average I assume that QEMU emulates instructions at O(n)
> efficiency.  In the worst-case, might self-modifying code change the
> efficiency of QEMU to another order of efficiency, such as O(n^2)?  Any
> thoughts would be greatly appreciated.  Thanks!

Depends what your N is.

Worst case for SMC (Self Modifying Code) is modifying code in the same TB 
(Translation Block) as the store instruction. This kind of fault requires 
O(tb_size) time, so executing a TB (assuming every insn traps) takes 
O(tb_size ^2) time.  However the page boundaries impose a hard limit on the 
size of a TB. 

Thus for N < TARGET_PAGE_SIZE worst case total execution time is O(N^2), but 
for N > TARGET_PAGE_SIZE total execution time is still O(N).

For SMC the constant factor may be orders of magnitude larger than for regular 
code.

Paul

      reply	other threads:[~2007-02-08 20:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08 20:01 [Qemu-devel] Time complexity for self-modifying code Michael Gagnon
2007-02-08 20:37 ` Paul Brook [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=200702082037.36905.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=mgagnon1@gmu.edu \
    --cc=qemu-devel@nongnu.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 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.