mm: cma: Contiguous Memory Allocator added
in [Kernel]
|
From: Daniel Walker on 21 Jul 2010 17:10 On Wed, 2010-07-21 at 22:56 +0200, Michał Nazarewicz wrote: > On Wed, 21 Jul 2010 22:45:43 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > > Your not hearing the issues.. IT'S TOO COMPLEX! Please remove it. > > Remove what exactly? Remove the command line option and all related code, or make it all a debug option. Arguing with me isn't going to help your cause. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Zach Pfeffer on 22 Jul 2010 01:00 On Tue, Jul 20, 2010 at 05:51:25PM +0200, Michal Nazarewicz wrote: > The Contiguous Memory Allocator framework is a set of APIs for > allocating physically contiguous chunks of memory. > > Various chips require contiguous blocks of memory to operate. Those > chips include devices such as cameras, hardware video decoders and > encoders, etc. > > The code is highly modular and customisable to suit the needs of > various users. Set of regions reserved for CMA can be configured on > run-time and it is easy to add custom allocator algorithms if one > has such need. > > Signed-off-by: Michal Nazarewicz <m.nazarewicz(a)samsung.com> > Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> > Reviewed-by: Pawel Osciak <p.osciak(a)samsung.com> > --- > Documentation/cma.txt | 435 +++++++++++++++++++ > Documentation/kernel-parameters.txt | 7 + > include/linux/cma-int.h | 183 ++++++++ > include/linux/cma.h | 92 ++++ > mm/Kconfig | 41 ++ > mm/Makefile | 3 + > mm/cma-allocators.h | 42 ++ > mm/cma-best-fit.c | 360 ++++++++++++++++ > mm/cma.c | 778 +++++++++++++++++++++++++++++++++++ > 9 files changed, 1941 insertions(+), 0 deletions(-) > create mode 100644 Documentation/cma.txt > create mode 100644 include/linux/cma-int.h > create mode 100644 include/linux/cma.h > create mode 100644 mm/cma-allocators.h > create mode 100644 mm/cma-best-fit.c > create mode 100644 mm/cma.c > > diff --git a/Documentation/cma.txt b/Documentation/cma.txt > new file mode 100644 > index 0000000..7edc20a > --- /dev/null > +++ b/Documentation/cma.txt > @@ -0,0 +1,435 @@ > + -*- org -*- > + > +* Contiguous Memory Allocator > + > + The Contiguous Memory Allocator (CMA) is a framework, which allows > + setting up a machine-specific configuration for physically-contiguous > + memory management. Memory for devices is then allocated according > + to that configuration. > + > + The main role of the framework is not to allocate memory, but to > + parse and manage memory configurations, as well as to act as an > + in-between between device drivers and pluggable allocators. It is > + thus not tied to any memory allocation method or strategy. > + This topic seems very hot lately. I recently sent out a few RFCs that implement something called a Virtual Contiguous Memory Manager that does what this patch does, and works for IOMMU and works for CPU mappings. It also does multihomed memory targeting (use physical set 1 memory for A allocations and use physical memory set 2 for B allocations). Check out: mm: iommu: An API to unify IOMMU, CPU and device memory management mm: iommu: A physical allocator for the VCMM mm: iommu: The Virtual Contiguous Memory Manager It unifies IOMMU and physical mappings by creating a one-to-one software IOMMU for all devices that map memory physically. It looks like you've got some good ideas though. Perhaps we can leverage each other's work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 22 Jul 2010 01:40 On Tue, 20 Jul 2010 18:12:39 -0600 Jonathan Corbet <corbet(a)lwn.net> wrote: > One other thing occurred to me as I was thinking about this... > > > + There are four calls provided by the CMA framework to devices. To > > + allocate a chunk of memory cma_alloc() function needs to be used: > > + > > + unsigned long cma_alloc(const struct device *dev, > > + const char *kind, > > + unsigned long size, > > + unsigned long alignment); > > The purpose behind this interface, I believe, is pretty much always > going to be to allocate memory for DMA buffers. Given that, might it > make more sense to integrate the API with the current DMA mapping > API? IMO, having separate APIs for allocating memory and doing DMA mapping is much better. The DMA API covers the latter well. We could extend the current API to allocate memory or create new one similar to the current. I don't see any benefit of a new abstraction that does both magically. About the framework, it looks too complicated than we actually need (the command line stuff looks insane). Why can't we have something simpler, like using memblock to reserve contiguous memory at boot and using kinda mempool to share such memory between devices? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marek Szyprowski on 22 Jul 2010 03:40 Hello, On Thursday, July 22, 2010 7:38 AM FUJITA Tomonori wrote: > On Tue, 20 Jul 2010 18:12:39 -0600 > Jonathan Corbet <corbet(a)lwn.net> wrote: > > > One other thing occurred to me as I was thinking about this... > > > > > + There are four calls provided by the CMA framework to devices. To > > > + allocate a chunk of memory cma_alloc() function needs to be used: > > > + > > > + unsigned long cma_alloc(const struct device *dev, > > > + const char *kind, > > > + unsigned long size, > > > + unsigned long alignment); > > > > The purpose behind this interface, I believe, is pretty much always > > going to be to allocate memory for DMA buffers. Given that, might it > > make more sense to integrate the API with the current DMA mapping > > API? > > IMO, having separate APIs for allocating memory and doing DMA mapping > is much better. The DMA API covers the latter well. We could extend > the current API to allocate memory or create new one similar to the > current. > > I don't see any benefit of a new abstraction that does both magically. That's true. DMA mapping API is quite stable and already working. > About the framework, it looks too complicated than we actually need > (the command line stuff looks insane). Well, this command line stuff was designed to provide a way to configure memory allocation for devices with very sophisticated memory requirements. It might look insane in first sight, but we haven't implemented it just for fun. We have just taken the real requirements for our multimedia devices (especially hardware video codec) tried to create a solution that would cover all of them. However I understand your point. It might be really good idea to set a default mapping as a "one global memory pool for all devices". This way the complicated cma boot argument would need to be provided only on machines that really require it, all other can use it without any advanced command line magic. > Why can't we have something simpler, like using memblock to reserve > contiguous memory at boot and using kinda mempool to share such memory > between devices? There are a few problems with such simple approach: 1. It does not provide all required functionality for our multimedia devices. The main problem is the fact that our multimedia devices require particular kind of buffers to be allocated in particular memory bank. Then add 2 more requirements: a proper alignment (for some of them it is even 128Kb) and particular range of addresses requirement (some buffers must be allocated at higher addresses than the firmware). This is very hard to achieve with such simple allocator. 2. One global memory pool heavily increases fragmentation issues and gives no way to control or limit it. The opposite solution - like having a separate pools per each multimedia device solves some fragmentation issues but it's a huge waste a of the memory. Our idea was to provide something configurable that can be placed between both solutions, that can take advantages of both. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marek Szyprowski on 22 Jul 2010 04:00
Hello, On Thursday, July 22, 2010 6:55 AM Zach Pfeffer wrote: > On Tue, Jul 20, 2010 at 05:51:25PM +0200, Michal Nazarewicz wrote: > > The Contiguous Memory Allocator framework is a set of APIs for > > allocating physically contiguous chunks of memory. > > > > Various chips require contiguous blocks of memory to operate. Those > > chips include devices such as cameras, hardware video decoders and > > encoders, etc. > > > > The code is highly modular and customisable to suit the needs of > > various users. Set of regions reserved for CMA can be configured on > > run-time and it is easy to add custom allocator algorithms if one > > has such need. > > > > Signed-off-by: Michal Nazarewicz <m.nazarewicz(a)samsung.com> > > Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> > > Reviewed-by: Pawel Osciak <p.osciak(a)samsung.com> > > --- > > Documentation/cma.txt | 435 +++++++++++++++++++ > > Documentation/kernel-parameters.txt | 7 + > > include/linux/cma-int.h | 183 ++++++++ > > include/linux/cma.h | 92 ++++ > > mm/Kconfig | 41 ++ > > mm/Makefile | 3 + > > mm/cma-allocators.h | 42 ++ > > mm/cma-best-fit.c | 360 ++++++++++++++++ > > mm/cma.c | 778 > +++++++++++++++++++++++++++++++++++ > > 9 files changed, 1941 insertions(+), 0 deletions(-) > > create mode 100644 Documentation/cma.txt > > create mode 100644 include/linux/cma-int.h > > create mode 100644 include/linux/cma.h > > create mode 100644 mm/cma-allocators.h > > create mode 100644 mm/cma-best-fit.c > > create mode 100644 mm/cma.c > > > > diff --git a/Documentation/cma.txt b/Documentation/cma.txt > > new file mode 100644 > > index 0000000..7edc20a > > --- /dev/null > > +++ b/Documentation/cma.txt > > @@ -0,0 +1,435 @@ > > + -*- org -*- > > + > > +* Contiguous Memory Allocator > > + > > + The Contiguous Memory Allocator (CMA) is a framework, which allows > > + setting up a machine-specific configuration for physically-contiguous > > + memory management. Memory for devices is then allocated according > > + to that configuration. > > + > > + The main role of the framework is not to allocate memory, but to > > + parse and manage memory configurations, as well as to act as an > > + in-between between device drivers and pluggable allocators. It is > > + thus not tied to any memory allocation method or strategy. > > + > > This topic seems very hot lately. I recently sent out a few RFCs that > implement something called a Virtual Contiguous Memory Manager that > does what this patch does, and works for IOMMU and works for CPU > mappings. It also does multihomed memory targeting (use physical set 1 > memory for A allocations and use physical memory set 2 for B > allocations). Check out: > > mm: iommu: An API to unify IOMMU, CPU and device memory management > mm: iommu: A physical allocator for the VCMM > mm: iommu: The Virtual Contiguous Memory Manager > > It unifies IOMMU and physical mappings by creating a one-to-one > software IOMMU for all devices that map memory physically. > > It looks like you've got some good ideas though. Perhaps we can > leverage each other's work. We are aware of your patches. However our CMA solves the problem that is a bit orthogonal to the setting up iommu. When you have IOMMU you don't really need to care about memory fragmentation. In CMA approach we had to care about it. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |