I am working on the tmpfs side on top of this patchset, which I assume has better applications usage than ramfs.
However, I am working on 3.3 so far and will probably get my patches ported to upstream pretty soon. I believe my patchset is also in early stage but it does help to get some solid numbers in our own projects, which is very convincing. However, I think it does depend on the characteristic of the job .....
Best wishes,
--
Ning Qu (曲宁) | Software Engineer | quning@xxxxxxxxxx | +1-408-418-6066
Ning Qu (曲宁) | Software Engineer | quning@xxxxxxxxxx | +1-408-418-6066
On Tue, Sep 24, 2013 at 4:37 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
On Mon, 23 Sep 2013 15:05:28 +0300 "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx> wrote:We were never going to do this :(
> It brings thp support for ramfs, but without mmap() -- it will be posted
> separately.
Has anyone reviewed these patches much yet?
It appears rather too immature at this stage.
> Please review and consider applying.
At the very least we should get this done for a real filesystem to see
> Intro
> -----
>
> The goal of the project is preparing kernel infrastructure to handle huge
> pages in page cache.
>
> To proof that the proposed changes are functional we enable the feature
> for the most simple file system -- ramfs. ramfs is not that useful by
> itself, but it's good pilot project.
how intrusive the changes are and to evaluate the performance changes.
Sigh. A pox on whoever thought up huge pages. Words cannot express
how much of a godawful mess they have made of Linux MM. And it hasn't
ended yet :( My take is that we'd need to see some very attractive and
convincing real-world performance numbers before even thinking of
taking this on.