From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MM: use DIV_ROUND_UP() in mm/memory.c
Date: Thu, 17 May 2007 23:51:10 +0200 [thread overview]
Message-ID: <200705172351.20394.eike-kernel@sf-tec.de> (raw)
In-Reply-To: <20070503202808.4f835c8a.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]
Andrew Morton wrote:
> Rolf Eike Beer wrote:
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -1838,12 +1838,11 @@ void unmap_mapping_range(struct address_space
>> *mapping,
>> {
>> struct zap_details details;
>> pgoff_t hba = holebegin >> PAGE_SHIFT;
>> - pgoff_t hlen = (holelen + PAGE_SIZE - 1) >> PAGE_SHIFT;
>> + pgoff_t hlen = DIV_ROUND_UP(holelen, PAGE_SIZE);
>>
>> /* Check for overflow. */
>> if (sizeof(holelen) > sizeof(hlen)) {
>> - long long holeend =
>> - (holebegin + holelen + PAGE_SIZE - 1) >> PAGE_SHIFT;
>> + long long holeend = DIV_ROUND_UP(holebegin + holelen, PAGE_SIZE);
>> if (holeend & ~(long long)ULONG_MAX)
>> hlen = ULONG_MAX - hba + 1;
>> }
>> @@ -2592,7 +2591,7 @@ int make_pages_present(unsigned long addr, unsigned
>> long end)
>> write = (vma->vm_flags & VM_WRITE) != 0;
>> BUG_ON(addr >= end);
>> BUG_ON(end > vma->vm_end);
>> - len = (end+PAGE_SIZE-1)/PAGE_SIZE-addr/PAGE_SIZE;
>> + len = DIV_ROUND_UP(end, PAGE_SIZE) - addr/PAGE_SIZE;
>> ret = get_user_pages(current, current->mm, addr,
>> len, write, 0, NULL, NULL);
>> if (ret < 0)
>
> More seriously, on i386:
>
> text data bss dec hex filename
> 15509 27 28 15564 3ccc mm/memory.o (before)
> 15561 27 28 15616 3d00 mm/memory.o (after)
>
> I'm not sure why - some of the quantities which we're dividing by there are
> 64-bit and perhaps the compiler has decided not to do shifting.
>
> Now I'm worried about all the other DIV_ROUND_UP() conversions we did. We
> should get in there and work out why it went bad.
It's the first two places that cause the increase in code size. The last one
is the exact replacement of how DIV_ROUND_UP() is defined so that can hardly
make a difference.
If the compiler can't find out to do shifting we might want to improve
DIV_ROUND_UP() to do some tricks with __builtin_constant_p() to do the shift.
Something like:
#define DIV_ROUND_UP(n, d) \
( \
__builtin_constant_p(d) ? ( \
is_power_of_2(d) ? \
(((n) + (d) - 1) >> ilog2(d)) : \
(((n) + (d) - 1) / (d)) \
) : \
(((n) + (d) - 1) / (d)) \
)
With this version mm/memory.o will result in the same size with and without my
patch so I guess it's doing what it should. If you like it tell me and I'll
send a patch.
Eike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2007-05-17 21:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-24 14:10 Rolf Eike Beer
2007-05-04 3:28 ` Andrew Morton
2007-05-17 21:05 ` Rolf Eike Beer
2007-05-17 21:51 ` Rolf Eike Beer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200705172351.20394.eike-kernel@sf-tec.de \
--to=eike-kernel@sf-tec.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox