Re: resend--[PATCH] improve read ahead in kernel
From: Roman Gushchin
Date: Thu Dec 20 2012 - 06:04:22 EST
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/