lkml.org 
[lkml]   [2000]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[patch-2.4.0-test10-pre3] logic of __alloc_pages_limit().
Hi Linus and Rik,

The same analysis I did for __alloc_pages() applies to
__alloc_pages_limit(), namely it can be optimized by looking at the logic
of 'page == NULL'. In both cases, of course, I checked the assembly
listing to make sure that my patch didn't make a worse code. It was always
a few instructions shorter and therefore worth it. (I didn't check whether
gcc produced fewer branches, I assume he did, otherwise he would be
totally braindead...).

Regards,
Tigran

--- linux/mm/page_alloc.c Sun Oct 15 20:40:38 2000
+++ work/mm/page_alloc.c Mon Oct 16 22:39:13 2000
@@ -262,15 +262,17 @@
}

if (z->free_pages + z->inactive_clean_pages >= water_mark) {
- struct page *page = NULL;
+ struct page *page;
/* If possible, reclaim a page directly. */
- if (direct_reclaim && z->free_pages < z->pages_min + 8)
+ if (direct_reclaim && z->free_pages < z->pages_min + 8) {
page = reclaim_page(z);
- /* If that fails, fall back to rmqueue. */
- if (!page)
- page = rmqueue(z, order);
- if (page)
- return page;
+ /* If that fails, fall back to rmqueue. */
+ if (!page) {
+ page = rmqueue(z, order);
+ if (page)
+ return page;
+ }
+ }
}
}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.027 / U:1.516 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site