lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 2 Oct 2008 15:44:46 +0900 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> To: Andy Whitcroft <apw@...dowen.org> Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, Peter Zijlstra <peterz@...radead.org>, Christoph Lameter <cl@...ux-foundation.org>, Rik van Riel <riel@...hat.com>, Mel Gorman <mel@....ul.ie>, Nick Piggin <nickpiggin@...oo.com.au>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [PATCH 0/4] Reclaim page capture v4 On Wed, 1 Oct 2008 13:30:57 +0100 Andy Whitcroft <apw@...dowen.org> wrote: > For sometime we have been looking at mechanisms for improving the availability > of larger allocations under load. One of the options we have explored is > the capturing of pages freed under direct reclaim in order to increase the > chances of free pages coelescing before they are subject to reallocation > by racing allocators. > > Following this email is a patch stack implementing page capture during > direct reclaim. It consits of four patches. The first two simply pull > out existing code into helpers for reuse. The third makes buddy's use > of struct page explicit. The fourth contains the meat of the changes, > and its leader contains a much fuller description of the feature. > > This update represents a rebase to -mm and incorporates feedback from > KOSAKI Motohiro. It also incorporates an accounting fix which was > preventing some captures. > > I have done a lot of comparitive testing with and without this patch > set and in broad brush I am seeing improvements in hugepage allocations > (worst case size) success on all of my test systems. These tests consist > of placing a constant stream of high order allocations on the system, > at varying rates. The results for these various runs are then averaged > to give an overall improvement. > > Absolute Effective > x86-64 2.48% 4.58% > powerpc 5.55% 25.22% > > x86-64 has a relatively small huge page size and so is always much more > effective at allocating huge pages. Even there we get a measurable > improvement. On powerpc the huge pages are much larger and much harder > to recover. Here we see a full 25% increase in page recovery. > > It should be noted that these are worst case testing, and very agressive > taking every possible page in the system. It would be helpful to get > wider testing in -mm. > > Against: 2.6.27-rc1-mm1 > > Andrew, please consider for -mm. > Hmm, can't we use "MIGRATE_ISOLATE" pageblock type for this purpose ? The page allocater skips pageblock marked as MIGRATE_ISOLATE at allocation. (pageblock-size is equal to HUGEPAGE size in general.) Of course, "where should be isolated" is a problem. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists