Messages in this thread | | | Date | Fri, 22 Mar 2013 07:44:56 -0700 | From | Dave Hansen <> | Subject | Re: [PATCHv2, RFC 07/30] thp, mm: introduce mapping_can_have_hugepages() predicate |
| |
On 03/22/2013 03:12 AM, Kirill A. Shutemov wrote: > Dave Hansen wrote: >> On 03/14/2013 10:50 AM, Kirill A. Shutemov wrote: >>> +static inline bool mapping_can_have_hugepages(struct address_space *m) >>> +{ >>> + if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { >>> + gfp_t gfp_mask = mapping_gfp_mask(m); >>> + return !!(gfp_mask & __GFP_COMP); >>> + } >>> + >>> + return false; >>> +} >> >> I did a quick search in all your patches and don't see __GFP_COMP >> getting _set_ anywhere. Am I missing something? > > __GFP_COMP is part of GFP_TRANSHUGE. We set it for ramfs in patch 20/30.
That's a bit non-obvious. For a casual observer, it _seems_ like you should just be setting and checking GFP_TRANSHUGE directly. It looks like you were having some problems with __GFP_MOVABLE and masked it out of GFP_TRANSHUGE and that has cascaded over to _this_ check.
I _think_ the right thing to do is add a comment up there in mapping_can_have_hugepages() that does (GFP_TRANSHUGE & ~__GFP_MOVABLE), and adds a TODO in the code and patch comments to clean it up once ramfs_get_inode() gets fixed up too.
| |