search for: dst_page

Hello Minchan, On (03/30/16 16:12), Minchan Kim wrote: [..] > @@ -1835,23 +1827,31 @@ static void __zs_compact(struct zs_pool *pool, struct size_class *class) > if (!migrate_zspage(pool, class, &cc)) > break; > > - putback_zspage(pool, class, dst_page); > + VM_BUG_ON_PAGE(putback_zspage(pool, class, > + dst_page) == ZS_EMPTY, dst_page); can this VM_BUG_ON_PAGE() condition ever be true? > } > /* Stop if we couldn't find slot */ > if (dst_page == NULL) > break; > - putback_zspage(pool, class, dst_page)...

Hello Minchan, On (03/30/16 16:12), Minchan Kim wrote: [..] > @@ -1835,23 +1827,31 @@ static void __zs_compact(struct zs_pool *pool, struct size_class *class) > if (!migrate_zspage(pool, class, &cc)) > break; > > - putback_zspage(pool, class, dst_page); > + VM_BUG_ON_PAGE(putback_zspage(pool, class, > + dst_page) == ZS_EMPTY, dst_page); can this VM_BUG_ON_PAGE() condition ever be true? > } > /* Stop if we couldn't find slot */ > if (dst_page == NULL) > break; > - putback_zspage(pool, class, dst_page)...

...gt; > On (03/30/16 16:12), Minchan Kim wrote: > [..] > > @@ -1835,23 +1827,31 @@ static void __zs_compact(struct zs_pool *pool, struct size_class *class) > > if (!migrate_zspage(pool, class, &cc)) > > break; > > > > - putback_zspage(pool, class, dst_page); > > + VM_BUG_ON_PAGE(putback_zspage(pool, class, > > + dst_page) == ZS_EMPTY, dst_page); > > can this VM_BUG_ON_PAGE() condition ever be true? I guess it is remained thing after I rebased to catch any mistake. But I'm heavily chainging this part. Please review next ve...

..._per_zspage, - &pool->pages_allocated); - - free_zspage(first_page); - } - return fullness; } @@ -1835,23 +1827,31 @@ static void __zs_compact(struct zs_pool *pool, struct size_class *class) if (!migrate_zspage(pool, class, &cc)) break; - putback_zspage(pool, class, dst_page); + VM_BUG_ON_PAGE(putback_zspage(pool, class, + dst_page) == ZS_EMPTY, dst_page); } /* Stop if we couldn't find slot */ if (dst_page == NULL) break; - putback_zspage(pool, class, dst_page); - if (putback_zspage(pool, class, src_page) == ZS_EMPTY) + VM_BUG_ON_PAGE(putba...

...p_atomic(d->src_addr); + kunmap_local(d->src_addr); d->src_addr = NULL; } if (unmap_dst) { - kunmap_atomic(d->dst_addr); + kunmap_local(d->dst_addr); d->dst_addr = NULL; } @@ -388,12 +388,8 @@ static int vmw_bo_cpu_blit_line(struct v if (WARN_ON_ONCE(dst_page >= d->dst_num_pages)) return -EINVAL; - d->dst_addr = - kmap_atomic_prot(d->dst_pages[dst_page], - d->dst_prot); - if (!d->dst_addr) - return -ENOMEM; - + d->dst_addr = kmap_local_page_prot(d->dst_pages[dst_page], + d->dst_prot); d-&g...

...class) if (inuse != freezed) { unfreeze_zspage(class, page, freezed); putback_zspage(class, page); + unlock_zspage(page, NULL); page = NULL; continue; } @@ -2076,11 +2143,13 @@ static void __zs_compact(struct zs_pool *pool, struct size_class *class) putback_zspage(class, dst_page); unfreeze_zspage(class, dst_page, class->objs_per_zspage); + unlock_zspage(dst_page, NULL); spin_unlock(&class->lock); dst_page = NULL; } if (zspage_empty(class, src_page)) { + unlock_zspage(src_page, NULL); free_zspage(pool, src_page); spin_lock(&amp...

Hi Minchan, [auto build test WARNING 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 coccinelle warnings: (new ones prefixed by >>) >>

Hi Minchan, [auto build test WARNING 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 coccinelle warnings: (new ones prefixed by >>) >>

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Hi gang, Here''s some trivial cleanups that I''ve built up while reading through the code. They''ve been run through xfstests -g quick. - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi, The following series of patches implements in btrfs an ioctl to do out-of-band deduplication of file extents. To be clear, this means that the file system is mounted and running, but the dedupe is not done during file writes, but after the fact when some userspace software initiates a dedupe. The primary patch is loosely based off of one sent by Josef Bacik back in January, 2011.

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all