From: "Jan Beulich" <JBeulich@novell.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
George Dunlap <george.dunlap@citrix.com>
Subject: Re: non-contiguous allocations
Date: Fri, 06 May 2011 11:45:10 +0100 [thread overview]
Message-ID: <4DC3ED560200007800040020@vpn.id2.novell.com> (raw)
In-Reply-To: <20110506102557.GA16863@aepfle.de>
>>> On 06.05.11 at 12:25, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Apr 26, Jan Beulich wrote:
>
>> >>> On 18.04.11 at 20:45, Olaf Hering <olaf@aepfle.de> wrote:
>> > On Fri, Apr 01, George Dunlap wrote:
>> >
>> >> On Wed, 2011-03-30 at 19:04 +0100, Olaf Hering wrote:
>> >> > Using the u16 means each cpu could in theory use up to 256MB as trace
>> >> > buffer. However such a large allocation will currently fail on x86 due
>> >> > to the MAX_ORDER limit.
>> >>
>> >> FWIW, I don't believe that there's any reason the allocations have to be
>> >> contiguous any more. I kept them contiguous to minimize the changes to
>> >> the moving parts near a release. But the new system has been pretty
>> >> well tested now, so I think looking at non-contiguous allocations may be
>> >> worthwhile.
>> >
>> > how do I allocate a few mfns and give them a virtual address?
>> > I dont find a malloc like interface to allocate random pages.
>
>> Otherwise I think the only option is to introduce indirection (using
>> the 1:1 mapping, and setting up an array of pointers). That may
>> however be a little difficult if (and I think that's the case) data
>> chunks aren't always of the same size (as then you need to deal
>> with the roll-over into the next page).
>
> I'm almost done with the per-page handling in __insert_record().
> I just need to figure out the a usable address of a given mfn.
> Is the u8 *p = mfn_to_virt(mfn) the same as page_to_virt(mfn_to_page(mfn))?
Yes.
Jan
>
> Olaf
next prev parent reply other threads:[~2011-05-06 10:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-30 18:04 [PATCH 0 of 3] xentrace updates Olaf Hering
2011-03-30 18:04 ` [PATCH 1 of 3] xentrace: correct formula to calculate t_info_pages Olaf Hering
2011-04-01 10:32 ` George Dunlap
2011-03-30 18:04 ` [PATCH 2 of 3] xentrace: use tbuf_size for overflow check Olaf Hering
2011-04-01 11:18 ` George Dunlap
2011-04-05 10:19 ` Olaf Hering
2011-04-07 13:50 ` Olaf Hering
2011-04-18 18:45 ` non-contiguous allocations Olaf Hering
2011-04-26 11:51 ` Jan Beulich
2011-05-06 10:25 ` Olaf Hering
2011-05-06 10:45 ` Jan Beulich [this message]
2011-05-06 18:12 ` Olaf Hering
2011-05-06 18:46 ` Keir Fraser
2011-05-07 8:39 ` Olaf Hering
2011-05-07 16:31 ` Keir Fraser
2011-05-09 8:30 ` Jan Beulich
2011-05-09 8:34 ` Keir Fraser
2011-05-09 12:43 ` Olaf Hering
2011-05-09 14:14 ` Keir Fraser
2011-03-30 18:04 ` [PATCH 3 of 3] xentrace: remove unneeded debug printk Olaf Hering
2011-04-01 11:18 ` George Dunlap
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=4DC3ED560200007800040020@vpn.id2.novell.com \
--to=jbeulich@novell.com \
--cc=george.dunlap@citrix.com \
--cc=olaf@aepfle.de \
--cc=xen-devel@lists.xensource.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;
as well as URLs for NNTP newsgroup(s).