Re: [PATCH] hugetlbfs: rework calculation code of Hugepage size in hugetlbfs_show_options()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi:
On 2021/2/1 18:56, David Hildenbrand wrote:
> On 01.02.21 09:23, Miaohe Lin wrote:
>> Rework calculation code of the Hugepage size to make it more readable and
>> straightforward.
>>
>> Signed-off-by: Miaohe Lin <linmiaohe@xxxxxxxxxx>
>> ---
>>   fs/hugetlbfs/inode.c | 9 +++++----
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index 3a08fbae3b53..1be18de4b537 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -1014,11 +1014,12 @@ static int hugetlbfs_show_options(struct seq_file *m, struct dentry *root)
>>       if (sbinfo->max_inodes != -1)
>>           seq_printf(m, ",nr_inodes=%lu", sbinfo->max_inodes);
>>   -    hpage_size /= 1024;
>> -    mod = 'K';
>> -    if (hpage_size >= 1024) {
>> -        hpage_size /= 1024;
>> +    if (hpage_size >= SZ_1M) {
>> +        hpage_size /= SZ_1M;
>>           mod = 'M';
>> +    } else {
>> +        hpage_size /= SZ_1K;
>> +        mod = 'K';
>>       }
>>       seq_printf(m, ",pagesize=%lu%c", hpage_size, mod);
>>       if (spool) {
>>
> 
> Looks correct but I am not convinced the old code was that complicated to understand.
> 

The old code is not complicated but I think it may be better to use macro instead of well-known "magic number".
Many thanks for review.:)





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux