Messages in this thread Patch in this message | | | Date | Mon, 16 Oct 2000 22:50:43 +0100 (BST) | From | Tigran Aivazian <> | 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/
| |