From: Jan Kiszka <jan.kiszka@siemens.com>
To: Avi Kivity <avi@redhat.com>
Cc: Sasha Levin <levinsasha928@gmail.com>,
kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH] MMIO: Make coalesced mmio use a device per zone
Date: Tue, 19 Jul 2011 19:14:19 +0200 [thread overview]
Message-ID: <4E25BB6B.90907@siemens.com> (raw)
In-Reply-To: <4E255D44.8000107@redhat.com>
On 2011-07-19 12:32, Avi Kivity wrote:
> On 07/19/2011 01:17 PM, Sasha Levin wrote:
>> On Tue, 2011-07-19 at 12:59 +0300, Avi Kivity wrote:
>> > On 07/19/2011 12:53 PM, Sasha Levin wrote:
>> > > > Make these per-guest instead of global. The lock may be
>> contended, and
>> > > > the list shouldn't hold items from different guests (why is
>> it needed,
>> > > > anyway?)
>> > > >
>> > >
>> > > We only need the list for removal, since we only have the range
>> we want
>> > > to remove, and we want to find all devices which contain this
>> range.
>> > >
>> >
>> > All devices in the same guest which contain this range. Your patch
>> > removes devices from all guests.
>> >
>>
>> Yup. I've messed up guest-locality. Will fix.
>>
>> Also, I found this comment when increasing NR_IOBUS_DEVS:
>>
>> /*
>> * It would be nice to use something smarter than a linear search,
>> TBD...
>> * Thankfully we dont expect many devices to register (famous last
>> words :),
>> * so until then it will suffice. At least its abstracted so we can
>> change
>> * in one place.
>> */
>>
>> Since so far we've registered 5-6 devices, and now it may increase
>> significantly (since we may want to do the same change to ioeventfds,
>> which work the same way) - how would you feel if we make devices
>> register range(s) and do a rbtree lookup instead of a linear search?
>>
>
> It makes sense. In fact your change is a good first step - so far it
> was impossible to to a clever search since the seaching code was not
> aware of the ranges (and could not be, since the single coalesced mmio
> device had multiple ranges).
>
> Rather than an rbtree, I suggest putting all ranges in an array and
> sorting it, then using binary search.
Another improvement - unfortunately less transparent for user space -
would be to overcome the single ring buffer that forces us to hold a
central lock in user space while processing the entries. We rather need
per-device rings. While waiting for coalesced VGA MMIO being processed,
way too many kittens are killed.
I have this on our agenda, but I wouldn't be disappointed as well if
someone else is faster.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2011-07-19 17:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 8:10 [PATCH] MMIO: Make coalesced mmio use a device per zone Sasha Levin
2011-07-19 8:48 ` Avi Kivity
2011-07-19 9:53 ` Sasha Levin
2011-07-19 9:59 ` Avi Kivity
2011-07-19 10:17 ` Sasha Levin
2011-07-19 10:32 ` Avi Kivity
2011-07-19 11:22 ` Sasha Levin
2011-07-19 11:45 ` Sasha Levin
2011-07-19 17:14 ` Jan Kiszka [this message]
2011-07-19 17:17 ` Avi Kivity
2011-07-19 17:23 ` Jan Kiszka
2011-07-19 19:28 ` Sasha Levin
2011-07-19 20:00 ` Jan Kiszka
2011-07-20 8:24 ` Avi Kivity
2011-07-20 8:43 ` Jan Kiszka
2011-07-20 8:52 ` Avi Kivity
2011-07-20 8:55 ` Jan Kiszka
2011-07-20 8:58 ` Avi Kivity
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=4E25BB6B.90907@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=mtosatti@redhat.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