search for: isolate_migratepages_rang

...> #include <asm/tlbflush.h> > @@ -76,7 +76,7 @@ int migrate_prep_local(void) > * from where they were once taken off for compaction/migration. > * > * This function shall be used whenever the isolated pageset has been > - * built from lru, balloon, hugetlbfs page. See isolate_migratepages_range() > + * built from lru, driver, hugetlbfs page. See isolate_migratepages_range() > * and isolate_huge_page(). > */ > void putback_movable_pages(struct list_head *l) > @@ -92,8 +92,8 @@ void putback_movable_pages(struct list_head *l) > list_del(&page->l...

...> #include <asm/tlbflush.h> > @@ -76,7 +76,7 @@ int migrate_prep_local(void) > * from where they were once taken off for compaction/migration. > * > * This function shall be used whenever the isolated pageset has been > - * built from lru, balloon, hugetlbfs page. See isolate_migratepages_range() > + * built from lru, driver, hugetlbfs page. See isolate_migratepages_range() > * and isolate_huge_page(). > */ > void putback_movable_pages(struct list_head *l) > @@ -92,8 +92,8 @@ void putback_movable_pages(struct list_head *l) > list_del(&page->l...

...lt;linux/mmu_notifier.h> #include <asm/tlbflush.h> @@ -76,7 +76,7 @@ int migrate_prep_local(void) * from where they were once taken off for compaction/migration. * * This function shall be used whenever the isolated pageset has been - * built from lru, balloon, hugetlbfs page. See isolate_migratepages_range() + * built from lru, driver, hugetlbfs page. See isolate_migratepages_range() * and isolate_huge_page(). */ void putback_movable_pages(struct list_head *l) @@ -92,8 +92,8 @@ void putback_movable_pages(struct list_head *l) list_del(&page->lru); dec_zone_page_state(page, NR_ISOLAT...

...IC, then fallback to the original gfp mask for the order-0 allocations. On systems that have highly fragmented main memory with pressure, skb_page_frag_refill() causes problems. mm enters significant compaction cycles on all cpu's which in itself is bad (add considerable spinlock contention in isolate_migratepages_range() for several seconds in kernel at 100% cpu), however even without this happening basically we have large memory reclaimation when only allocations from order-3 were necessary. For example, I might see half the existing page cache on a system (2GB out of 8GB) reclaimed in a burst, which effectivel...

...IC, then fallback to the original gfp mask for the order-0 allocations. On systems that have highly fragmented main memory with pressure, skb_page_frag_refill() causes problems. mm enters significant compaction cycles on all cpu's which in itself is bad (add considerable spinlock contention in isolate_migratepages_range() for several seconds in kernel at 100% cpu), however even without this happening basically we have large memory reclaimation when only allocations from order-3 were necessary. For example, I might see half the existing page cache on a system (2GB out of 8GB) reclaimed in a burst, which effectivel...

This patchset follows the main idea discussed at 2012 LSFMMS section: "Ballooning for transparent huge pages" -- http://lwn.net/Articles/490114/ to introduce the required changes to the virtio_balloon driver, as well as changes to the core compaction & migration bits, in order to allow memory balloon pages become movable within a guest. Rafael Aquini (4): mm: introduce compaction

This patchset follows the main idea discussed at 2012 LSFMMS section: "Ballooning for transparent huge pages" -- http://lwn.net/Articles/490114/ to introduce the required changes to the virtio_balloon driver, as well as changes to the core compaction & migration bits, in order to allow memory balloon pages become movable within a guest. Rafael Aquini (4): mm: introduce compaction

...nal > gfp mask for the order-0 allocations. > > On systems that have highly fragmented main memory with pressure, > skb_page_frag_refill() causes problems. mm enters significant > compaction cycles on all cpu's which in itself is bad (add > considerable spinlock contention in isolate_migratepages_range() for > several seconds in kernel at 100% cpu), however even without this > happening basically we have large memory reclaimation when only > allocations from order-3 were necessary. For example, I might see half > the existing page cache on a system (2GB out of 8GB) reclaimed in a &gt...

...m 2GB out of 8GB. >> >> There is a reason PAGE_ALLOC_COSTLY_ORDER exists and is 3 Sorry 2GB cache out of 8GB phys, ~1GB gets reclaimed. Regardless the reclaimation of cache is minor compared to the compaction event that precedes it, I haven't spotted something addressing that yet - isolate_migratepages_range ()/compact_checklock_irqsave(). If even more of memory was unmoveable, the compaction routines would be hit even harder as reclaimation wouldn't do anything - mm would have to get very very smart about unmoveable pages being freed and just fail allocations/oom kill if nothing has changed witho...

Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver

Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver

...100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -157,8 +157,8 @@ void putback_movable_page(struct page *page) * from where they were once taken off for compaction/migration. * * This function shall be used whenever the isolated pageset has been - * built from lru, balloon, hugetlbfs page. See isolate_migratepages_range() - * and isolate_huge_page(). + * built from lru, movable, hugetlbfs page. + * See isolate_migratepages_range() and isolate_huge_page(). */ void putback_movable_pages(struct list_head *l) { @@ -173,9 +173,7 @@ void putback_movable_pages(struct list_head *l) list_del(&page->lru);...

...100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -147,8 +147,8 @@ void putback_movable_page(struct page *page) * from where they were once taken off for compaction/migration. * * This function shall be used whenever the isolated pageset has been - * built from lru, balloon, hugetlbfs page. See isolate_migratepages_range() - * and isolate_huge_page(). + * built from lru, movable, hugetlbfs page. + * See isolate_migratepages_range() and isolate_huge_page(). */ void putback_movable_pages(struct list_head *l) { @@ -163,9 +163,7 @@ void putback_movable_pages(struct list_head *l) list_del(&page->lru);...

On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote: > > My suggestion is to use a recent kernel, and/or eventually backport the > mm fixes if any. > > order-3 allocations should not reclaim 2GB out of 8GB. > > There is a reason PAGE_ALLOC_COSTLY_ORDER exists and is 3 Hmm... it looks like I missed __GFP_NORETRY diff --git a/net/core/sock.c b/net/core/sock.c index

On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote: > > My suggestion is to use a recent kernel, and/or eventually backport the > mm fixes if any. > > order-3 allocations should not reclaim 2GB out of 8GB. > > There is a reason PAGE_ALLOC_COSTLY_ORDER exists and is 3 Hmm... it looks like I missed __GFP_NORETRY diff --git a/net/core/sock.c b/net/core/sock.c index

Hi Minchan, [auto build test ERROR on next-20160318] [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339 config: x86_64-randconfig-x000-201612 (attached as .config) reproduce: # save

Hi Minchan, [auto build test ERROR on next-20160318] [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339 config: x86_64-randconfig-x000-201612 (attached as .config) reproduce: # save

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge