On Monday 04 July 2011, Ankita Garg wrote:
It still sounds to me that this can be done using the NUMA properties
that Linux already understands, and teaching more subsystems about it,
but maybe the memory hotplug developers have already come up with
another scheme. The way that memory
Hi,
On Thu, Jun 16, 2011 at 12:06:07AM +0200, Arnd Bergmann wrote:
On Wednesday 15 June 2011 23:39:58 Larry Bassel wrote:
On 15 Jun 11 10:36, Marek Szyprowski wrote:
On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
On Wednesday, June 15, 2011 09:37:18 Arnd Bergmann wrote:
On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote:
I see your concerns, but I really wonder how to determine the properties
of the global/default cma pool. You definitely don't want to give all
available memory o CMA, because
On Wed, 22 Jun 2011 09:03:30 +0200, Hans Verkuil hverk...@xs4all.nl
wrote:
What I was wondering about is how this patch series changes the
allocation in case it can't allocate from the CMA pool. Will it
attempt to fall back to a 'normal' allocation?
Unless Marek changed something since I
On Wednesday 22 June 2011, Hans Verkuil wrote:
How about a Kconfig option that defines the percentage of memory
to set aside for contiguous allocations?
I would actually like to see a cma_size kernel option of some sort. This would
be for the global CMA pool only as I don't think we should
Hello,
On Wednesday, June 22, 2011 2:42 PM Arnd Bergmann wrote:
On Wednesday 22 June 2011, Hans Verkuil wrote:
How about a Kconfig option that defines the percentage of memory
to set aside for contiguous allocations?
I would actually like to see a cma_size kernel option of some sort.
On Wednesday 22 June 2011, Marek Szyprowski wrote:
Sounds really good, but it might be really hard to implemnt, at least for
CMA, because it needs to tweak parameters of memory management internal
structures very early, when buddy allocator has not been activated yet.
Why that? I would expect
On Wednesday, June 22, 2011 2:42 PM Arnd Bergmann wrote:
We could also go further and add a runtime sysctl mechanism like the
one for hugepages, where you can grow the pool at run time as long
as there is enough free contiguous memory (e.g. from init scripts),
or shrink it later if you want to
On Wed, 22 Jun 2011 15:39:23 +0200, Arnd Bergmann a...@arndb.de wrote:
Why that? I would expect you can do the same that hugepages (used to) do
and just attempt high-order allocations. If they succeed, you can add
them as a CMA region and free them again, into the movable set of pages,
On Thursday 16 June 2011 19:01:33 Larry Bassel wrote:
Can you describe how the memory areas differ specifically?
Is there one that is always faster but very small, or are there
just specific circumstances under which some memory is faster than
another?
One is always faster, but very
On Wednesday 15 June 2011, Daniel Vetter wrote:
On Tue, Jun 14, 2011 at 20:30, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote:
Ah yes, I forgot that separate regions for different purposes could
decrease fragmentation.
That is indeed a good
On Thursday 16 June 2011 02:48:12 Philip Balister wrote:
On 06/15/2011 12:37 AM, Arnd Bergmann wrote:
On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote:
I see your concerns, but I really wonder how to determine the properties
of the global/default cma pool. You definitely don't want
On 16 Jun 11 00:06, Arnd Bergmann wrote:
On Wednesday 15 June 2011 23:39:58 Larry Bassel wrote:
On 15 Jun 11 10:36, Marek Szyprowski wrote:
On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank
Hello,
On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs, with
Samsung, that makes 3 major SoC vendors (I would be surprised if
Nvidia didn't also need to do this) - so
On Tue, 14 Jun 2011 22:42:24 +0200, Arnd Bergmann a...@arndb.de wrote:
* We still need to solve the same problem in case of IOMMU mappings
at some point, even if today's hardware doesn't have this combination.
It would be good to use the same solution for both.
I don't think I follow.
On Wednesday 15 June 2011, Michal Nazarewicz wrote:
On Tue, 14 Jun 2011 22:42:24 +0200, Arnd Bergmann a...@arndb.de wrote:
* We still need to solve the same problem in case of IOMMU mappings
at some point, even if today's hardware doesn't have this combination.
It would be good to use
On Tuesday 14 June 2011, Jordan Crouse wrote:
On 06/14/2011 02:42 PM, Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs, with
Samsung, that makes 3 major SoC vendors (I would be surprised if
Nvidia
On Wed, 15 Jun 2011 13:20:42 +0200, Arnd Bergmann a...@arndb.de wrote:
The point is that on the higher level device drivers, we want to
hide the presence of CMA and/or IOMMU behind the dma mapping API,
but the device drivers do need to know about the bank properties.
Gotcha, thanks.
--
Best
On Tue, Jun 14, 2011 at 20:30, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote:
Ah yes, I forgot that separate regions for different purposes could
decrease fragmentation.
That is indeed a good point, but having a good allocator algorithm
could
On 06/15/2011 01:53 PM, Daniel Vetter wrote:
On Tue, Jun 14, 2011 at 20:30, Arnd Bergmanna...@arndb.de wrote:
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote:
Ah yes, I forgot that separate regions for different purposes could
decrease fragmentation.
That is indeed
On 15 Jun 11 10:36, Marek Szyprowski wrote:
Hello,
On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs, with
Samsung, that makes 3 major SoC vendors (I would be
On Wednesday 15 June 2011 23:39:58 Larry Bassel wrote:
On 15 Jun 11 10:36, Marek Szyprowski wrote:
On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs, with
On 06/15/2011 12:37 AM, Arnd Bergmann wrote:
On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote:
I see your concerns, but I really wonder how to determine the properties
of the global/default cma pool. You definitely don't want to give all
available memory o CMA, because it will have
On 15 June 2011 16:39, Larry Bassel lbas...@codeaurora.org wrote:
On 15 Jun 11 10:36, Marek Szyprowski wrote:
Hello,
On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs,
Hi,
On Tue, Jun 14, 2011 at 06:03:00PM +0200, Arnd Bergmann wrote:
On Tuesday 14 June 2011, Michal Nazarewicz wrote:
On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann a...@arndb.de wrote:
Please explain the exact requirements that lead you to defining multiple
contexts.
Some devices
On 14 June 2011 12:01, Daniel Stone dani...@collabora.com wrote:
Hi,
On Tue, Jun 14, 2011 at 06:03:00PM +0200, Arnd Bergmann wrote:
On Tuesday 14 June 2011, Michal Nazarewicz wrote:
On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann a...@arndb.de wrote:
Please explain the exact
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs, with
Samsung, that makes 3 major SoC vendors (I would be surprised if
Nvidia didn't also need to do this) - so I think some configurable
method to control allocations is
On 06/14/2011 02:42 PM, Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs, with
Samsung, that makes 3 major SoC vendors (I would be surprised if
Nvidia didn't also need to do this) - so I think some
28 matches
Mail list logo
