Re: resend--[PATCH] improve read ahead in kernel

[Roman Gushchin]

Hi Simon,

20.12.2012, 10:21, "Simon Jeons" <simon.jeons@xxxxxxxxx>:
> On Sun, 2012-12-16 at 02:15 +0000, Eric Wong wrote:
>
>>  xtu4 <xiaobing.tu@xxxxxxxxx> wrote:
>>>  resend it, due to format error
>>>
>>>  Subject: [PATCH] when system in low memory scenario, imaging there is a mp3
>>>   play, ora video play, we need to read mp3 or video file
>>>   from memory to page cache,but when system lack of memory,
>>>   page cache of mp3 or video file will be reclaimed.once read
>>>   in memory, then reclaimed, it will cause audio or video
>>>   glitch,and it will increase the io operation at the same
>>>   time.
>>  To me, this basically describes how POSIX_FADV_NOREUSE should work.
>
> Hi Eric,
>
> But why fadvise POSIX_FADV_NOREUSE almost do nothing? Why not set some
> flag or other things for these use once data?

Because, it's not clear how should it work in some cases.
Do we expect one access? Should we track a page as accessed after any access (even if only one byte was read)?
What should we do with already-cached pages? etc.

IMHO, it will be better to introduce something like POSIX_FADV_DONTCACHE.
Corresponding pages can be added (ratated) to the tail of the inactive LRU after copying data in read() internals,
or after minor/major pagefault.

>
>>  I would like to have this ability via fadvise (and not CONFIG_).
>>
>>  Also, I think your patch has too many #ifdefs to be accepted.
>>
>>  --
>>  To unsubscribe, send a message with 'unsubscribe linux-mm' in
>>  the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
>>  see: http://www.linux-mm.org/ .
>>  Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/