On Fri, 3 Apr 2009, Mark Lord wrote:
quoted text
> 
> Note that for mythtv, this may not be the best behaviour.
> 
> A common use scenario is "watching live TV", a few minutes behind
> real-time so that the commercial-skipping can work its magic.
> 
> In that scenario, those pages are going to be needed again
> within a short while, and it might be useful to keep them around.
> 
> But then Myth itself could probably decide whether to discard them
> or not, not based upon that kind of knowledge.

Yes. I suspect that Myth could do heuristics like "when watching live TV, 
do drop-behind about 30s after the currently showing stream". That still 
allows for replay, but older stuff you've watched really likely isn't all 
that interesting and migth be worth dropping in order to make room for 
more data.

And you can use posix_fadvise() for that, since it's now no longer 
connected with "wait for background IO to complete" at all.

The reason for wanting "SYNC_FILE_RANGE_DROP" was simply that I was doing 
the "wait after write" anyway, and thinking I wanted to get rid of the 
pages while I was already handling them. But that was for an app where I 
_new_ the data was uninteresting as soon as it was on disk. Doing a secure 
delete is different from recording video ;)

				Linus
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/