On 11/10/15 09:39, Naoya Horiguchi wrote:
> On Tue, Nov 10, 2015 at 05:41:08AM +0800, Chen Gang wrote:
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 2ce04a6..a515260 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -2988,12 +2988,7 @@ out:
>> */
>> int may_expand_vm(struct mm_struct *mm, unsigned long npages)
>
> marking inline?
>
For me, inline is OK. But I guess, it depends on the members tastes: "It
is used at 5 areas within mm, inline will expand the binary size".
>> {
>> - unsigned long cur = mm->total_vm; /* pages */
>> - unsigned long lim;
>> -
>> - lim = rlimit(RLIMIT_AS) >> PAGE_SHIFT;
>> -
>> - if (cur + npages > lim)
>> + if (mm->total_vm + npages > (rlimit(RLIMIT_AS) >> PAGE_SHIFT))
>> return 0;
>> return 1;
>
> How about doing simply
>
> return mm->total_vm + npages <= (rlimit(RLIMIT_AS) >> PAGE_SHIFT);
>
For me, only one line is OK. But I guess, it also depends on the members
tastes: does it let code a little complex?
If we can use bool instead of int for may_epand_mm() return value, I
guess, one line implementation (your idea) will be OK to all members.
> ? These changes save some bytes :)
>
> text data bss dec hex filename
> 20566 2250 40 22856 5948 mm/mmap.o (before)
>
> text data bss dec hex filename
> 20542 2250 40 22832 5930 mm/mmap.o (after)
>
> Thanks,
> Naoya Horiguchi
>
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href