[lkml]   [2013]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [PATCHv2, RFC 20/30] ramfs: enable transparent huge page cache
    On Tue, 2 Apr 2013, Kirill A. Shutemov wrote:
    > Kirill A. Shutemov wrote:
    > > From: "Kirill A. Shutemov" <>
    > >
    > > ramfs is the most simple fs from page cache point of view. Let's start
    > > transparent huge page cache enabling here.
    > >
    > > For now we allocate only non-movable huge page. It's not yet clear if
    > > movable page is safe here and what need to be done to make it safe.
    > >
    > > Signed-off-by: Kirill A. Shutemov <>
    > > ---
    > > fs/ramfs/inode.c | 6 +++++-
    > > 1 file changed, 5 insertions(+), 1 deletion(-)
    > >
    > > diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
    > > index c24f1e1..da30b4f 100644
    > > --- a/fs/ramfs/inode.c
    > > +++ b/fs/ramfs/inode.c
    > > @@ -61,7 +61,11 @@ struct inode *ramfs_get_inode(struct super_block *sb,
    > > inode_init_owner(inode, dir, mode);
    > > inode->i_mapping->a_ops = &ramfs_aops;
    > > inode->i_mapping->backing_dev_info = &ramfs_backing_dev_info;
    > > - mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
    > > + /*
    > > + * TODO: what should be done to make movable safe?
    > > + */
    > > + mapping_set_gfp_mask(inode->i_mapping,
    > Hugh, I've found old thread with the reason why we have GFP_HIGHUSER here, not
    > It seems the origin reason is not longer valid, correct?

    Incorrect, I believe: so far as I know, the original reason remains
    valid - though it would only require a couple of good small changes
    to reverse that - or perhaps you have already made these changes?

    The original reason is that ramfs pages are not migratable,
    therefore they should be allocated from an unmovable area.

    As I understand it (and I would have preferred to run a test to check
    my understanding before replying, but don't have time for that), ramfs
    pages cannot be migrated for two reasons, neither of them a good reason.

    One reason (okay, it wouldn't have been quite this way in 2006) is that
    ramfs (rightly) calls mapping_set_unevictable(), so its pages will fail
    the page_evictable() test, so they will be marked PageUnevictable, so
    __isolate_lru_page() will refuse to isolate them for migration (except
    for CMA).

    I am strongly in favour of removing that limitation from
    __isolate_lru_page() (and the thread you pointed - thank you - shows Mel
    and Christoph were both in favour too); and note that there is no such
    restriction in the confusingly similar but different isolate_lru_page().

    Some people do worry that migrating Mlocked pages would introduce the
    occasional possibility of a minor fault (with migration_entry_wait())
    on an Mlocked region which never faulted before. I tend to dismiss
    that worry, but maybe I'm wrong to do so: maybe there should be a
    tunable for realtimey people to set, to prohibit page migration from
    mlocked areas; but the default should be to allow it.

    (Of course, we could separate ramfs's mapping_unevictable case from
    the Mlocked case; but I'd prefer to continue to treat them the same.)

    The other reason it looks as if ramfs pages cannot be migrated, is
    that it does not set a suitable ->migratepage method, so would be
    handled by fallback_migrate_page(), whose PageDirty test will end
    up failing the migration with -EBUSY or -EINVAL - if I read it

    Perhaps other such reasons would surface once those are fixed.
    But until ramfs pages can be migrated, they should not be allocated
    with __GFP_MOVABLE. (I've been writing about the migratability of
    small pages: I expect you have the migratability of THPages in flux.)


     \ /
      Last update: 2013-04-03 00:41    [W:0.029 / U:40.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site