public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Muli Ben-Yehuda <muli@il.ibm.com>
To: Grant Grundler <grundler@google.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	linux-kernel@vger.kernel.org, mgross@linux.intel.com,
	linux-scsi@vger.kernel.org
Subject: Re: Intel IOMMU (and IOMMU for Virtualization) performances
Date: Sat, 7 Jun 2008 00:36:59 +0300	[thread overview]
Message-ID: <20080606213659.GC15085@il.ibm.com> (raw)
In-Reply-To: <da824cf30806061428t4b7ed816i74d961946d77c88b@mail.gmail.com>

On Fri, Jun 06, 2008 at 02:28:36PM -0700, Grant Grundler wrote:

> Historically the IOMMUs needed physically contiguous memory and
> resizing essentially meant quiescing all DMA, moving the IO Pdir
> data to the new bigger location, allocating a new bitmap and cloning
> the state into that as well, and then resuming DMA operations. The
> DMA quiesce requirement effectively meant a reboot. My understanding
> of Vt-d is the ranges can be added range at a time and thus can be
> easily resized.

VT-d uses a multi-level page-table, so there would be no problem
resizing.

> But it will mean more complex logic in the IOMMU bitmap handling for
> a domain which owns multiple bitmaps and thus a slightly higher CPU
> utilization cost. At least that's my guess. I'm not working on any
> IOMMU code lately...

The logic seems pretty simple to me, all we need to do is keep track
of how many entries are currently allocated in the bitmap vs. the size
of the bitmap. Once we get to the half-way point, double the size of
the bitmap. Having said that, I'm not sure it's worth it, and have no
plans to implement it :-)

Cheers,
Muli

  reply	other threads:[~2008-06-06 21:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-04 14:47 Intel IOMMU (and IOMMU for Virtualization) performances FUJITA Tomonori
2008-06-04 16:56 ` Andi Kleen
2008-06-05 14:49   ` FUJITA Tomonori
2008-06-04 18:06 ` Grant Grundler
2008-06-05 14:49   ` FUJITA Tomonori
2008-06-05 18:34     ` Grant Grundler
2008-06-05 19:01       ` James Bottomley
2008-06-06  4:44         ` FUJITA Tomonori
2008-06-06  5:48           ` Grant Grundler
2008-06-09  9:36             ` FUJITA Tomonori
2008-06-06 20:23     ` Muli Ben-Yehuda
2008-06-06 20:21   ` Muli Ben-Yehuda
2008-06-06 21:28     ` Grant Grundler
2008-06-06 21:36       ` Muli Ben-Yehuda [this message]
2008-06-06 21:51         ` Grant Grundler
2008-06-09  8:17           ` Andi Kleen
2008-06-09  9:36             ` FUJITA Tomonori
2008-06-09 10:20               ` Andi Kleen
2008-06-05 22:02 ` mark gross
2008-06-06  4:44   ` FUJITA Tomonori
2008-06-23 17:54     ` mark gross

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=20080606213659.GC15085@il.ibm.com \
    --to=muli@il.ibm.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=grundler@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    /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