From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com, mark.williamson@cl.cam.ac.uk,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>
Subject: Re: [Patch] by default don't give all memory to dom0
Date: Fri, 19 Aug 2005 18:20:31 -0700 [thread overview]
Message-ID: <20050819182031.B4564@unix-os.sc.intel.com> (raw)
In-Reply-To: <6320da47ae30ead9a43bc18b7e878ae9@cl.cam.ac.uk>; from Keir.Fraser@cl.cam.ac.uk on Fri, Aug 19, 2005 at 09:44:03AM +0100
On Fri, Aug 19, 2005 at 09:44:03AM +0100, Keir Fraser wrote:
>
> On 18 Aug 2005, at 20:24, Siddha, Suresh B wrote:
>
> > By default, xen needs to reserve some portion of memory to satisfy
> > SWIOTLB and other contguous memory region requests. Following
> > the current swiotlb enabling mechanism, Appended patch reserves 128MB
> > of memory on systems with more than 2GB of RAM.
>
> Hmmm... sounds reasonable. I'd rather have one dom0 memory parameter
> though --- keeping dom0_mem but have +ve value mean 'allocate this
> amount' and -ve mean 'allocate full memory - this amount'. Otherwise we
> have two competing parameters specifying basically the same thing...
>
> I don't much like hacky 'policies' that hardcode default reservations
> in the hypervisor, but I think this one is pretty sensible.
I see this incorporated in changeset #6257. Thanks.
> > Ideally shouldn't we enable SWIOTLB in dom0 and this DMA memory
> > reservation
> > in hypervisor by default? Otherwise we will have a problem(even on
> > systems
> > with less than 2GB of RAM) in servicing a driver DMA request to a
> > kmalloc'd buffer which spans more than a page or the various
> > xen_create_contiguous_region() requests.
>
> You get a pretty clear BUG() message out if this happens. It actually
> tells you to enable 'swiotlb=force'! The number of drivers that
> actually use multi-page buffers is really small -- we only fixed that
If we decide not to support(/fix) those drivers, then we should enable
swiotlb only if the system has more than 4GB of RAM. Where is the current
2GB magic figure coming from?
> case in 2.0 a few weeks ago.
>
> I'd rather not waste 64MB of pre-reserved bounce buffers on
> small-memory systems that almost certainly don't need bounce buffers.
We can have a smaller swiotlb window (couple of MB?) on small-memory systems
if we want to support the drivers doing dma_map_single to multipage buffers.
thanks,
suresh
prev parent reply other threads:[~2005-08-20 1:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-18 19:24 [Patch] by default don't give all memory to dom0 Siddha, Suresh B
2005-08-18 19:50 ` David Hopwood
2005-08-18 20:28 ` Siddha, Suresh B
2005-08-18 21:55 ` David Hopwood
2005-08-19 0:13 ` Siddha, Suresh B
2005-08-19 8:31 ` Keir Fraser
2005-08-19 23:32 ` Default memory unit David Hopwood
2005-08-20 0:58 ` [Patch] by default don't give all memory to dom0 Siddha, Suresh B
2005-08-19 8:44 ` Keir Fraser
2005-08-19 13:45 ` Mark Williamson
2005-08-20 1:20 ` Siddha, Suresh B [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=20050819182031.B4564@unix-os.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=mark.williamson@cl.cam.ac.uk \
--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 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.