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

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

Klaus Schmidinger wrote:
> Carsten Koch wrote:
>
> > Hi,
> >
> > we have discussed this subject here before.
> > I believe we consent that the main reason for the big delays
> > when opening the recordings menu is the fact that vdr reads
> > and writes huge amounts of data from/to the nnn.vdr files,
> > the kernel tries to cache these, thus moving much more useful
> > stuff (like cached directory entries and cached small files)
> > out of the memory cache.
> > It usually makes no sense at all to cache the nnn.vdr files,
> > as they normally are read/written only once.
> >
> > I recently found out that kernels > 2.4.9 seem to have exactly
> > the solution we were looking for.
> >
> > From "man 2 open":
> >
> >        O_DIRECT
> >               Try to minimize cache effects of  the  I/O  to  and
> >               from  this file.  In general this will degrade per­
> >               formance, but it is useful in  special  situations,
> >               such  as  when  applications  do their own caching.
> >               File  I/O  is  done  directly  to/from  user  space
> >               buffers.  The I/O is synchronous, i.e., at the com­
> >               pletion of the read(2)  or  write(2)  system  call,
> >               data   is  guaranteed  to  have  been  transferred.
> >               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 flag is supported on  a  number  of  Unix-like
> >               systems;  support  was  added under Linux in kernel
> >               version 2.4.10.
> >               A semantically similar interface for block  devices
> >               is described in raw(8).
> >
> > I guess a patch that uses this should be trivial.
> > I have not tried it yet.
> > Is there anything obvious that speaks against this being a nice
> > solution fo our problem?
>
> 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.

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?



> 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...

Carsten.



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