MM: use DIV_ROUND_UP() in mm/memory.c

PATCH In review Rolf Eike Beer 2 participants 4 messages Apr 24, 2007 – May 17, 2007

Subsystems (2)

Memory management MM core

lore

Share & tools

lore

Rolf Eike Beer

author

2007-04-24 14:11 UTC #0 lore raw

PATCH 1/1 MM: use DIV_ROUND_UP() in mm/memory.c

This should make no difference in behaviour.

Signed-off-by Rolf Eike Beer <[email protected]>

---
commit 64aa7c3136258d3abc76354b5f83b9a9575169c0
tree 8037adc04b57cd6150456399b7caccf99489385a
parent bf0bd376f79cadb4f8cd454db1723eb9be0aabc1
author Rolf Eike Beer <[email protected]> Tue, 24 Apr 2007 16:05:40 +0200 committer Rolf Eike Beer <[email protected]> Tue, 24 Apr 2007 16:05:40 +0200

 mm/memory.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

mm/memory.c +0 -0

index e7066e7..45bba1f 100644
@@ -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)

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

Andrew Morton

maintainer

2007-05-04 03:28 UTC #1 lore raw

Quoted 44 lines · On Tue, 24 Apr 2007 16:10:22 +0200 Rolf Eike Beer <[email protected]> wrote:

This should make no difference in behaviour.

Signed-off-by Rolf Eike Beer <[email protected]>

 mm/memory.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

mm/memory.c +2 -3

index e7066e7..45bba1f 100644
@@ -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;

mm/memory.c +1 -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);

Quoted 1 line

if (ret < 0)

The patch is wordwrapped. Please fix your MUA.

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.

Please always check the before-and-after .text size from now on?

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.

Rolf Eike Beer

author

2007-05-17 21:05 UTC #2 lore raw

PATCH 1/1 MM: use DIV_ROUND_UP() in mm/memory.c

Replace a hand coded version of DIV_ROUND_UP().

Signed-off-by Rolf Eike Beer <[email protected]

---
commit ab35916f807eb4f2019a208e96cb0bddbb91dfc3
tree 6dc4485902c1a96a09ed287270de108630b26719
parent 335aa0289219ca2c1dc309d6bf856d4b25ad8746
author Rolf Eike Beer <[email protected]> Thu, 17 May 2007 23:03:06 +0200 committer Rolf Eike Beer <[email protected]> Thu, 17 May 2007 23:03:06 +0200

 mm/memory.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

mm/memory.c +1 -1

index cb94488..5bc26b7 100644
@@ -2674,7 +2674,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)

Rolf Eike Beer

author

2007-05-17 21:51 UTC #3 lore raw

In reply to Andrew Morton

Quoted 34 lines · Andrew Morton

Quoted 27 lines · Rolf Eike Beer

mm/memory.c +2 -3

@@ -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;

mm/memory.c +1 -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);

Quoted 1 line

if (ret < 0)

More seriously, on i386:

text data bss dec hex filename

Quoted 8 lines

  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