> On Wednesday 28 July 2010 11:04:56 Marek Szyprowski wrote:
On Sun, 01 Aug 2010 15:26:13 +0200, Hans Verkuil <hverkuil@xs4all.nl> wrote:
I've been thinking about providing a "fake" region with a "fake" allocator which
would allow in a generic way passing requests to kmalloc() and friends. Such
regions could prove valuable for small allocations in things like 3D accelerator.
But as you've said, it's better to provide something small first and later add to
it so I'm postponing implementation of this feature.
Note, however, that 3D accelerator does not operate only on small chunks of memory.
A 1024x1024 texture is 1 Mipx. RGB makes it 3MiB. With mipmap it's 4MiB. Even
512x512 texture can reach 1MiB this way. It ma be impossible to allocate such
chunks with just a kmalloc().
But the point is that driver does not allocate memory at boot time. If video
codec would allocate memory at boot time no one else could use it even if the
codec is not used. The idea is to make other devices use the memory when
codec is idle. For instance, one could work on huge JPEG images and need
buffers for a hardware JPEG codec.
Or have I misunderstood your point?
Our intention is that driver would allocate buffers only when needed so the buffers
would be freed when video codec driver is released. So when the device is opened
(whatever that would mean for a particular device) it would allocate enough memory
for the requested task.
Yes, this is our experience. The best-fit algorithm, even though simple, seem to
handle use cases tested on our system with little fragmentation.
I'm trying to keep it as simple as possible :) still making it useful for us.
In particular we need a way to specify where different regions reside (different
memory banks, etc.) as well as specify which drivers should use which regions.
What's more, we need the notion of a "kind" of memory as one driver may need
memory buffers from different regions (ie. MFC needs to allocate buffers from
both banks).
1. Everyone seem to hate the command line interface that was present in the
first and second version of the patch. As such, I've made it optional
(via Kconfig option) in the third version (not posted yet), which
unfortunately makes platform initialisation code longer and more
complicated but hopefully more people will be happy. ;)
2. We need to specify size, alignment and start address so those are not
hypothetical.
3. The algorithms are somehow hypothetical (we haven't tried using a different
allocator as of you) but I think it's much easier to design the whole system
with them in mind and implement them in the first version then later add code
for them.
I may also add that adding this actually made me refactor the code a bit
making it more readable in the end I think. :)
Please note that kmalloc() was not designed to handle big chunks of memory
and vmalloc() does not give a contiguous memory blocks. This is usually
reason enough for a custom allocator that operates on a big region of memory
reserved at boot time.
For instance, if some driver operates on buffers that are between 512 KiB and 4 MiB
(as I've shown above such sizes could well be required for textures) it needs to
reserve some big region of contiguous memory and then manage it by itself.
One of CMA's goals is to give a common API for drivers that need such allocators.
This particular thing was suggested by someone I think. Or maybe someone wrote
something that make me think about it? Someone suggested that drivers may want
to just grab some region of memory and have it for themselves. Even though I'd
rather see them using the other set of CMA APIs but nonetheless it may prove
useful for someone.
This is especially true for devices with their own memory which only their
driver should have access to. I admit that it is a bit hypothetical though.
At any rate, with a changes made between the first and the second (this one)
versions of the patch private regions were actually trivial to add. This
merely mimics the way regions are reserved at boot time so the code is
simply identical to what platform initialisation code may use. The only
thing that make private regions special is the fact that they have no name.
Not exactly... The first version of the patch provided fewer features and
this was mostly what we needed on our platform with maybe a few features
that weren't a must.
After posting we received some comments and suggestions which made my change
the code a bit making it more flexible and dynamic at the same time letting
more features in.
Let me rephrase it to see if I got it correct:
You propose that platform will define what types of memory it has. For instance
banka for a the first bank, bankb for the second memory bank, dma for DMA-able
memory, etc. Those definitions would be merely informative and by themselves
they would not reserve any memory.
Later, it would be possible to specify regions of memory of those types. For
instance:
banka=20M; banka/foo,bar=30M
would register two regions in the memory type "banka" such that the first is 20 MiB
and used by all drivers expect for driver foo and bar which would use the second
region of 30 MiB?
So the driver would request a memory type "banka" and then get a chunk from one of
the abovementioned regions?
I somehow like the simplicity of that but I see some disadvantages:
1. Imagine a video decoder which for best performance should operate on some buffers
from the first and some buffers from the second bank. However, if the buffers are
from the incorrect bank it will still work, only slower. In such situations you
cannot specify that when driver foo requests memory type "banka" then it should
first try memory type "banka" but if allocation failed there try "bankb".
2. What if the device handled by the above driver were run on a platform with only
one memory bank? The driver would still refer to "banka" and "bankb" but there
would be no such types in the system.
3. What if there were one driver, initially written for platform X which used names
"banka" and "bankb", and another driver, initially written for platform Y which
used names "bank1" and "bank2". How would you make them work on a single platform
with two memory banks?
4. This is hypothetical, but the "kind" defined by CMA could be used to specify
characteristics that are not hardware dependent. For instance some driver
could use kind "bulk" for some big, several MiB buffers and "control" for
small less then MiB buffers. Regions for those kinds could be of the same
type of memory but it could be valuable splitting those to two regions to
minimise fragmentation.
I think that driver should not care about or know region names at all.
As I've said somewhere above, I was thinking about something like it.
I think the main difference between your proposal and what is in CMA is that you
propose that platform define types of memory and later on user will be able to
define regions of given type of memory. This means that drivers would have to
be aware of the names of the types and specify the type name witch each allocation.
The CMA solution however, lets drivers define their own kinds of memory and later
on platform initialisation code map drivers with their kinds to regions.
Have I got it right?
--
Best regards, _ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał "mina86" Nazarewicz (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
--
