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 memo
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 wro
On Wed, 22 Jun 2011 15:39:23 +0200, Arnd Bergmann 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,
otherwise you just
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 al
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 expe
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 s
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
On Wed, 22 Jun 2011 09:03:30 +0200, Hans Verkuil
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 wrote the code, which
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, b
On Wednesday 15 June 2011, Daniel Vetter wrote:
> On Tue, Jun 14, 2011 at 20:30, Arnd Bergmann 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 po
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
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 thi
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 do
On 15 June 2011 16:39, Larry Bassel 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, 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 nega
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 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 wou
On 06/15/2011 01:53 PM, Daniel Vetter wrote:
On Tue, Jun 14, 2011 at 20:30, Arnd Bergmann 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,
On Tue, Jun 14, 2011 at 20:30, Arnd Bergmann 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 also solv
On Wed, 15 Jun 2011 13:20:42 +0200, Arnd Bergmann 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 regards,
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
> >>
On Wednesday 15 June 2011, Michal Nazarewicz wrote:
> On Tue, 14 Jun 2011 22:42:24 +0200, Arnd Bergmann 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
On Wednesday 15 June 2011, Marek Szyprowski wrote:
> > > If possible I would like to make cma something similar to
> > > declare_dma_coherent()&friends, so the board/platform/bus startup code
> > > will just call declare_dma_contiguous() to enable support for cma for
> > > particular devices.
> >
On Tue, 14 Jun 2011 22:42:24 +0200, Arnd Bergmann 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. What does IOMMU h
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)
Hello,
On Wednesday, June 15, 2011 9: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
Hello,
On Tuesday, June 14, 2011 3:49 PM Arnd Bergmann wrote:
> On Monday 13 June 2011, Marek Szyprowski wrote:
> > cm_alloc/free are definitely not meant to be called from device drivers.
> > They should be only considered as a backend for dma-mapping.
> >
> > 'Raw' contiguous memory block doesn
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 negative impact on kernel
> operation (kernel
Hello,
On Tuesday, June 14, 2011 8:30 PM Arnd Bergmann wrote:
> On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote:
> > On Tue, 14 Jun 2011 18:03:00 +0200, Arnd Bergmann wrote:
> > > For all I know, that is something that is only true for a few very
> > > special Samsung devices,
> >
> > Ma
Hi Arnd,
On 06/14/2011 09:33 PM, Arnd Bergmann wrote:
On Tuesday 14 June 2011, Michal Nazarewicz wrote:
On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann wrote:
Please explain the exact requirements that lead you to defining multiple
contexts.
Some devices may have access only to some banks
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 configurable
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 necess
On 14 June 2011 12:01, Daniel Stone 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 wrote:
>> > > Please explain the exact requirements that lead you to defi
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote:
Is having support for multiple regions a bad thing? Frankly,
removing this support will change code from reading context passed
as argument to code reading context from global variable. Nothing
is gained; functionality is lost.
On Tue,
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote:
> On Tue, 14 Jun 2011 18:03:00 +0200, Arnd Bergmann wrote:
> > For all I know, that is something that is only true for a few very
> > special Samsung devices,
>
> Maybe. I'm just answering your question. :)
>
> Ah yes, I forgot that sep
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 wrote:
> > > Please explain the exact requirements that lead you to defining multiple
> > > contexts.
> >
> > Some devices
On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann wrote:
Please explain the exact requirements that lead you to defining
multiple contexts.
On Tuesday 14 June 2011, Michal Nazarewicz wrote:
Some devices may have access only to some banks of memory. Some devices
may use different banks of m
On Tuesday 14 June 2011, Michal Nazarewicz wrote:
> On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann wrote:
> > Please explain the exact requirements that lead you to defining multiple
> > contexts.
>
> Some devices may have access only to some banks of memory. Some devices
> may use different
On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann wrote:
Please explain the exact requirements that lead you to defining multiple
contexts.
Some devices may have access only to some banks of memory. Some devices
may use different banks of memory for different purposes.
--
Best regards,
On Monday 13 June 2011, Marek Szyprowski wrote:
> cm_alloc/free are definitely not meant to be called from device drivers.
> They should be only considered as a backend for dma-mapping.
>
> 'Raw' contiguous memory block doesn't really make sense for the device
> drivers. What the drivers require is
Hello,
On Friday, June 10, 2011 6:22 PM Arnd Bergmann wrote:
> On Friday 10 June 2011, Marek Szyprowski wrote:
> >The Contiguous Memory Allocator is a set of functions that lets
> >one initialise a region of memory which then can be used to perform
> >allocations of contiguous memory chunks from.
On Friday 10 June 2011, Marek Szyprowski wrote:
>The Contiguous Memory Allocator is a set of functions that lets
>one initialise a region of memory which then can be used to perform
>allocations of contiguous memory chunks from.
>
>CMA allows for creation of separate contexts. Kernel is allowed to
The Contiguous Memory Allocator is a set of functions that lets
one initialise a region of memory which then can be used to perform
allocations of contiguous memory chunks from.
CMA allows for creation of separate contexts. Kernel is allowed to
allocate movable pages within CMA's managed memory so
43 matches
Mail list logo
