[Ksummit-2013-discuss] [ATTEND] Transparent huge pagecache

Kirill A. Shutemov kirill at shutemov.name
Mon Jul 8 13:43:09 UTC 2013


On Mon, Jul 08, 2013 at 02:31:26PM +0200, Jan Kara wrote:
>   Hi,
> 
> On Mon 08-07-13 15:03:54, Kirill A. Shutemov wrote:
> > Current Transparent Huge Pages implementation is limited to anonymous
> > memory mapping. I work on adding support of huge pages in pagecache and
> > enabling it for most simple filesystem -- ramfs. The patchset is mostly
> > ready, although it hasn't got much review yet.
> >
> > I would like to discuss upstreaming of the feature and future steps --
> > enabling it for more useful filesystems: tmpfs and, probably, some
> > filesystem with backing storage (ext4?).
> > One other possible application is THP as backend for hugetlb interface.
>   So I was watching the patch series from distance and when considering
> "standard" filesystems such as ext4 a few questions come to mind: I presume
> you handle dirtying by splitting a huge page? If yes, the usefulness is
> limited to read only data and there's some cost of the additional split,
> coalescing huge pages etc. So the question is whether it's worth it.

I haven't evaluated it closely yet, but the initial plan was to add
hugepages to pagecache only if nobody has the file opened on write and use
small pages otherwise. This way we can avoid most of split-on-dirtying
overhead with minimal effort and we will get most of elf executables and
libraries mapped with huge pages which is not bad for start.

We can consider more complex solution later. At the moment I have no
experience with writeback code to be more specific.

> Or do you plan to somehow track partial dirtiness? We already do that in
> buffer heads when blocksize < pagesize but here the scale is considerably
> different so the algorithms we use would need changes I presume.

Hugh previously proposed[1] to rework tail pages refcounting, but it's a
big project which (according to Andrea) will require get_user_pages() API
breakage. Probably, I will look on this in details at some point.

[1] http://lkml.org/lkml/2013/1/30/589
-- 
 Kirill A. Shutemov


More information about the Ksummit-2013-discuss mailing list