[Bug 691299] API: GstFileMemAllocator - an allocator that uses disk storage to provide memory space

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=691299
  GStreamer | gst-plugins-base | git

--- Comment #14 from Sebastian Dröge (slomo) <slomo at circular-chaos.org> 2013-08-12 11:34:53 UTC ---
(In reply to comment #12)
> (In reply to comment #10)
> > Review of attachment 250246 [details] [details]:
> > 
> > ::: gst-libs/gst/allocators/gstmappedfile.c
> > @@ +162,3 @@
> > +      maxsize);
> > +
> > +  if (allocator->f_offset_next + maxsize > allocator->file_size) {
> > 
> > I think you should implement a better block allocation strategy, that allows to
> > properly deallocate and reallocate blocks
> > 
> > @@ +207,3 @@
> > +     of blocks available or more advanced if needed. */
> > +
> > +#if defined (HAVE_FALLOCATE) && HAVE_DECL_FALLOC_FL_PUNCH_HOLE
> > 
> > So if this is not supported, the memory will slowly run full and then nothing
> > can be allocated anymore? I think the allocator should not be supported at all
> > then
> 
> This allocator is bound to run out of space sooner or later as it's supposed to
> be intialised with a specific total size.  The reason for this is that there's
> no way to reliably resize the file if any of its mmap()-ed blocks have been
> given out and are in use.  I'd like it wasn't true so please let me know if I'm
> wrong here.

No, that's true unfortunately. Having a fixed size is ok, as long as blocks can
be reused.

> I agree that not reusing freed blocks is poor but given my reasoning above it's
> not the end of the world.  I agree reusing blocks should be supported (and
> should be a condition to accept this allocator at all) but there are at least
> two ways to approach it:
> - declare the allocator to allocate blocks of a certain size only
> This makes it dead simple as it boils down to maintaining a list of free blocks
> 
> - support arbitrary block size allocations
> This requires merging subsequent free blocks (buddy allocation, defragmentation
> etc.).

Yeah I agree that this is not trivial :) But without that this allocator isn't
really that useful, it will always go out of memory sooner or later. Going with
fixed (configurable) size blocks in the beginning would be a good start I
guess.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.