It's confusing that set_max_huge_pages() contained two different 
variables named "ret", and although the code works correctly this should 
be fixed.

The inner of the two variables can simply be removed.

Spotted by sparse.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 mm/hugetlb.c |    1 -
 1 file changed, 1 deletion(-)

--- linux-2.6/mm/hugetlb.c.old  2008-02-24 23:17:52.000000000 +0200
+++ linux-2.6/mm/hugetlb.c      2008-02-24 23:26:07.000000000 +0200
@@ -518,45 +518,44 @@
 static unsigned long set_max_huge_pages(unsigned long count)
 {
        unsigned long min_count, ret;
 
        /*
         * Increase the pool size
         * First take pages out of surplus state.  Then make up the
         * remaining difference by allocating fresh huge pages.
         *
         * We might race with alloc_buddy_huge_page() here and be unable
         * to convert a surplus huge page to a normal huge page. That is
         * not critical, though, it just means the overall size of the
         * pool might be one hugepage larger than it needs to be, but
         * within all the constraints specified by the sysctls.
         */
        spin_lock(&hugetlb_lock);
        while (surplus_huge_pages && count > persistent_huge_pages) {
                if (!adjust_pool_surplus(-1))
                        break;
        }
 
        while (count > persistent_huge_pages) {
-               int ret;
                /*
                 * If this allocation races such that we no longer need the
                 * page, free_huge_page will handle it by freeing the page
                 * and reducing the surplus.
                 */
                spin_unlock(&hugetlb_lock);
                ret = alloc_fresh_huge_page();
                spin_lock(&hugetlb_lock);
                if (!ret)
                        goto out;
 
        }
 
        /*
         * Decrease the pool size
         * First return free pages to the buddy allocator (being careful
         * to keep enough around to satisfy reservations).  Then place
         * pages into surplus state as needed so the pool will shrink
         * to the desired size as pages become free.
         *
         * By placing pages into the surplus state independent of the
         * overcommit value, we are allowing the surplus pool size to
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to