Re: [RFC][PATCH 2/2] HugeTLB mapping for drivers (export functions/identification of htlb mappings)

[Alexey Korolev <akorolex@gmail.com>]

> This needs to be explained better. What non-hugetlbfs file can have a
> hugepage mapping? You might mean drivers but they don't exist at this
> point so someone looking at the changelog in isolation might get
> confused.
>
Right. I'll add more text explanations. We need to provide hugepage maping for
device nodes which are not the elements of hugetlbfs.

>> +EXPORT_SYMBOL(hugetlb_get_unmapped_area);
>>
>
> I think the patch that exports symbols from hugetlbfs needs to be a
> separate patch explaining why they need to be exported for drivers to
> take advantage of.
Agree. It will be splited.

>>       ima_counts_get(file);
>> +     mapping_set_hugetlb(file->f_mapping);

> At a first reading, I was not getting why there needs to be a new way
> of identifying if a mapping is hugetlbfs-backed or not.  I get that it's
> because drivers will have file_operations that we cannot possibly know about
> in advance, particularly if they are loaded as modules but this really needs
> it's own patch and changelog spelling it out.

Right! Indeed this should be a place of attention. We must identify that file
is hugepage to identify unaccunable_mapping before vma got created. Currently
it is done for all files in hugetlbfs and there is a very special
workaround for
ipc/shm.c. If we have different drivers we workaround will not work
for us. So we
must find another approach to identify that file has very special
(huge page) mapping.
Currently I still in doubts if it is Ok to involve mapping flags or
not, but I did not find any other
option/marker to idenify that file has htlb mapping.

> It also again raises the
> question of why drivers would not use the internal hugetlbfs mount like
> shm does.
It is possible to use either ways. Unfortunately it is unclear which is better.
If make something like shm does - driver code get much complicated and
hardreadible.
We need to export file operations structure. We need to do hack
looking tricks with substitution of file->f_mapping.
If make something like done in this patch - driver code get simplier.
We need to export two file operations functions.
Involving of which also looks inconsistent.
Probably the best way would be - moving some functionality of
hugetlb_get_unmapped_area and hugetlbfs_file_mmap out of hugetlbfs.
And represent it as interface functions of hugetlb.c. In fact
hugetlb_get_unmapped_area never need file argument. It only needs
hstate to make addresses aligned and set up some architecture specific
registers. For drivers we need very small part of hugetlbfs_file_mmap
function as well.
In this case we will have interfaces for drivers which are completely
isolated from hugetlbfs.

>> +struct page *hugetlb_alloc_pages_node(int nid, gfp_t gfp_mask);
>> +void hugetlb_free_pages(struct page *page);
>
> This looks like it belongs in the previous patch.
>
>> +#define hugetlb_alloc_pages_node(nid, gfp_mask) 0
>> +#define hugetlb_free_pages(page) BUG();
>> +
>> +
>
> Ditto and some unnecessary whitespace there.
>
Yep. Sorry. I had to split it up and clean.

>
> Having the new exports and the new method for identifying if a file or
> mapping is hugetlbfs in the same patch does make this harder. I see
> nothing wrong with the above changes as such but I'm hard-wired into
> thinking that everything in a patch is directly related.
>
Acked.
>>  static inline struct hstate *hstate_inode(struct inode *i)
>>  {
>>       struct hugetlbfs_sb_info *hsb;
>> -     hsb = HUGETLBFS_SB(i->i_sb);
>> -     return hsb->hstate;
>> +     if (i->i_sb->s_magic == HUGETLBFS_MAGIC) {
>> +             hsb = HUGETLBFS_SB(i->i_sb);
>> +             return hsb->hstate;
>> +     }
>> +     return &hstate_nores;
>
> This needs a comment and the changelog needs to spell out better that you are
> expanding what hugetlbfs is. This chunk is basically saying that it's possible
> to have an inode that is backed by hugepages but that is not a hugetlbfs
> file. Your changelog needs to explain why hugetlbfs files were not created
> in the same way they are created for shared memory mappings on the internal
> hugetlbfs mount. Maybe we discussed this before but I forget the reasoning.

Yes. You are right. We did not discuss it before. It was one of the
problem being
faced during enbling Huge pages mapping for drivers. I've just
explained in the beginning of
this message.

>> +static inline int mapping_hugetlb(struct address_space *mapping)
>> +{
>> +     if (likely(mapping))
>> +             return test_bit(AS_HUGETLB, &mapping->flags);
>> +     return !!mapping;
>> +}
>
> That !!mapping looks a bit unnecessary.  Why is !!NULL always going to
> evaluate to 0?  I know it's copying from mapping_unevictable(), but that
> doesn't help me figure out why it looks like that.
This construction stunned me for a while also :). The only reason why this
construction could be used here is converting NULL to integer 0. IMHO
the best is "return 0"

Thanks,
Alexey

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>