[mythtv-commits] Ticket #9458: [patch] posix_fadvice usage

[MythTV]

#9458: [patch] posix_fadvice usage
----------------------------------------+----------------------------
 Reporter:  jiri.fojtasek@…             |          Owner:  danielk
     Type:  Patch - Bug Fix             |         Status:  assigned
 Priority:  minor                       |      Milestone:  0.25
Component:  MythTV - General            |        Version:  Trunk Head
 Severity:  medium                      |     Resolution:
 Keywords:                              |  Ticket locked:  0
----------------------------------------+----------------------------

Comment (by Jiri Fojtasek <jiri.fojtasek@…>):

 Replying to [comment:1 danielk]:
 > Jiri, I noticed that one of the fixes was signed by a "--setra". Is
 there a thread somewhere with longer explanations of each of the changes?
 The main thing I see here is that these advise calls appear to be
 interpreted globally rather than per file descriptor. i.e. if process A is
 reading file X on fd 2 at location 1024 and process B is writing to X fd 3
 then when B issues a POSIX_FADV_WONTNEED for the data before location
 2048, process A now needs to read from the disk rather than reading from
 the cache. This would be caused by the OS is not being smart enough to
 realize that even if process B doesn't plan to read the file soon, process
 A is reading the file with the SEQUENTIAL attribute and will soon read
 bytes 1025 through 2048.

 [[BR]]

 Page cache (or just file cache) are shared per physical file not per file
 descriptor so its global. Opening a file than have portion in the cache
 and calling DONTNEED will clear it from the cache.

 If you writing to a file and continuously flushung content from the cache
 by calling DONTNEED (both parameters zero will flush whole cache for given
 file) and another reader will always read the content from the disc
 instead of cache read ahead algorithm will be negated because read ahead
 should happen imeediately after read call and continuously are flushed by
 writer. For this reason is smart to flush only content we really do not
 need for both reader and writer process. About this is this patch.

 I started play with this before to fix problem than mythtv continuously
 filling file cache with cached streams and pushing out other more
 importand cached data and in even worse scenario causing program space
 pages swaped out with default vm.vfs_cache_pressure settings. Then i found
 than you played with this in the trunk and and only finely tuned the needs
 :)

 I using mythtv at relative slow computer and starting any application
 after a hour of watching mythv was really slow ...

 '''blockdev --setra''' is standart linux command with parameter to set
 number of sectors will be readahead from file by OS when its accessed
 (hdparm can do the same thing).

 Before i started play with mythv code i played a lot with programs from
 this page:
 http://insights.oetiker.ch/linux/fadvise/
 There are two programs. One is to flush a file from the cache and second
 show pages in cache used by the file. I used it also to test if my changes
 are corect at live tv stream and it show me for example need to swap order
 of killing threads in threadedfilewriter.

 Jiri

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/9458#comment:2>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center