[vdr] Re: Recordings menu sluggish - *the* solution.

[Carsten Koch <Carsten.Koch@icem.com>]

Klaus Schmidinger wrote:
...
> > > The only thing that might be a problem is
> > >
> > >        Transfer sizes, and the alignment  of  user  buffer
> > >        and  file offset must all be multiples of the logi­
> > >        cal block size of the file system.
> > >
> > > This might make things more complicated than just setting
> > > the O_DIRECT flag.
> > Oops, you are right.
> > What would be involved in order to align everything to, say, 4k boundaries?
> > I guess every I-frame should start at such a 4k boundary as well, which would
> > make it unnecessary to special-case the treatment of the first block when using
> > the fast forward/backward and jump functions.
>
> I'm afraid this would require some major "surgery", because as it
> is now VDR assumes that it can simply read a frame no matter what
> size it is, and at any file offset.
If that would get complicated, you could simply read the entire
block in which the frame starts and ignore the first bytes.



> > Of course the limitation that data must be aligned to 4k boundaries gives me
> > the feeling that vdr performance will actually *improve* quite a bit when you
> > use O_DIRECT, as the kernel can then DMA directly between the device and VDRs
> > buffers in user space, right?
>
> Maybe, but we would probably need an additional layer of data
> handling inside VDR for this.
>
>
> > > Apart from that the idea seems good, since then the system
> > > probably wouldn't lose the directory information.
> > It would be wonderful if that would work.
> > I had equipped my vdr with 512MB of RAM when I first noticed that its original
> > 128MB were always full. Of course, as we know now, that did not help at all...
>
> The whole problem, AFAICS, is that Linux uses the entire available
> RAM (or at least most of it) as disk buffer. So when large files are
> handled, all other things are dropped.
>
> Maybe it would help if there was a way to tell the kernel to
> use only that much RAM for buffering a particular file? Don't
> know, though, whether there actually is such a feature...
Even if there were, every byte of buffer allocated for the nnn.vdr
files is a wasted byte. I'd rather keep that memory for all my
other (vdr and non-vdr) files to improve overall system performance.


> The recording directory handling will be changed, anyway, to
> keep the information readily available. Maybe then this whole
> thing won't be a problem any more...
Yes, but that solution is complicated as well and it would be a
wasted effort after implementing O_DIRECT. And O_DIRECT gives
us 300% of the usefulness:

*  O_DIRECT solves the "Recordings menu sluggish" problem in an
   elegant way.

*  It makes all of VDR I/O on nnn.vdr files faster, as the kernel
   can DMA directly between the device and the VDR buffer.

*  It increases the performance of the entire system, by eliminating
   the overhead of moving gigabytes of data in and out of the cache
   needlessly and by keeping the cache memory available for useful data.

Carsten.



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.