similar to: [RFC PATCH 1/2] mm: multigen-LRU: working set reporting

This adds a leak decoder callback so that slab destruction can use to generate debugging output for the allocated objects. Callers like btrfs are using their own leak tracking which will manage allocated objects in a list(or something else), this does indeed the same thing as what slab does. So adding a callback for leak tracking can avoid this as well as runtime overhead. (The idea is from

This adds a leak decoder callback so that kmem_cache_destroy() can use to generate debugging output for the allocated objects. Callers like btrfs are using their own leak tracking which will manage allocated objects in a list(or something else), this does indeed the same thing as what slab does. So adding a callback for leak tracking can avoid this as well as runtime overhead. Signed-off-by:

ZONE_DEVICE struct pages have an extra reference count that complicates the code for put_page() and several places in the kernel that need to check the reference count to see that a page is not being used (gup, compaction, migration, etc.). Clean up the code so the reference count doesn't need to be treated specially for device private pages, leaving DAX as still being a special case.

On Wed, Aug 14, 2019 at 09:59:19AM +0200, Christoph Hellwig wrote: > There isn't any good reason to pass callbacks to migrate_vma. Instead > we can just export the three steps done by this function to drivers and > let them sequence the operation without callbacks. This removes a lot > of boilerplate code as-is, and will allow the drivers to drastically > improve code flow and

On Wed, 30 Mar 2016 16:11:59 +0900 Minchan Kim <minchan at kernel.org> wrote: > 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,

On (03/30/16 16:11), Andrew Morton wrote: [..] > > For details, please read description in > > "mm/compaction: support non-lru movable page migration". > > OK, I grabbed all these. > > I wonder about testing coverage during the -next period. How many > people are likely to exercise these code paths in a serious way before > it all hits mainline? I'm

On Wed, Mar 30, 2016 at 04:11:59PM +0900, Minchan Kim wrote: > 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

On Wed, 27 Apr 2016 16:48:13 +0900 Minchan Kim <minchan at kernel.org> wrote: > Recently, I got many reports about perfermance degradation in embedded > system(Android mobile phone, webOS TV and so on) and easy fork fail. > > The problem was fragmentation caused by zram and GPU driver mainly. > With memory pressure, their pages were spread out all of pageblock and > it

On Thu, Jun 16, 2016 at 05:42:11PM +0900, Sergey Senozhatsky wrote: > On (06/16/16 15:47), Minchan Kim wrote: > > > [..] > > > > > this is what I'm getting with the [zsmalloc: keep first object offset in struct page] > > > > > applied: "count:0 mapcount:-127". which may be not related to zsmalloc at this point. > > > > > >

On (03/30/16 16:11), Andrew Morton wrote: [..] > > For details, please read description in > > "mm/compaction: support non-lru movable page migration". > > OK, I grabbed all these. > > I wonder about testing coverage during the -next period. How many > people are likely to exercise these code paths in a serious way before > it all hits mainline? I'm

On Thu, Jun 16, 2016 at 05:42:11PM +0900, Sergey Senozhatsky wrote: > On (06/16/16 15:47), Minchan Kim wrote: > > > [..] > > > > > this is what I'm getting with the [zsmalloc: keep first object offset in struct page] > > > > > applied: "count:0 mapcount:-127". which may be not related to zsmalloc at this point. > > > > > >

On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote: > On 06/16/2016 05:56 AM, Minchan Kim wrote: > > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: > >> On 06/15/2016 08:02 AM, Minchan Kim wrote: > >>> Hi, > >>> > >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote: > >>>>>

Hello Gioh, On Tue, Jun 02, 2015 at 04:27:40PM +0900, Gioh Kim wrote: > 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

On Wed, 1 Jun 2016 08:21:09 +0900 Minchan Kim <minchan at kernel.org> wrote: > Recently, I got many reports about perfermance degradation in embedded > system(Android mobile phone, webOS TV and so on) and easy fork fail. > > The problem was fragmentation caused by zram and GPU driver mainly. > With memory pressure, their pages were spread out all of pageblock and > it

Hi, On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote: > On 05/31/2016 05:31 AM, Minchan Kim wrote: > > @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, struct page *newpage, > > int rc = -EAGAIN; > > int page_was_mapped = 0; > > struct anon_vma *anon_vma = NULL; > > + bool is_lru = !__PageMovable(page); > > >

On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: > On 06/15/2016 08:02 AM, Minchan Kim wrote: > > Hi, > > > > On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote: > >> > On 05/31/2016 05:31 AM, Minchan Kim wrote: > >>> > > @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, struct page *newpage, >

On Mon, May 16, 2016 at 04:17:51PM +0900, Sergey Senozhatsky wrote: > On (05/09/16 11:20), Minchan Kim wrote: > [..] > > +++ b/include/linux/migrate.h > > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES]; > > > > #ifdef CONFIG_MIGRATION > > > > +extern int PageMovable(struct page *page); > > +extern void __SetPageMovable(struct

On 05/31/2016 02:01 AM, Minchan Kim wrote: > Per Vlastimi's review comment. > > Thanks for the detail review, Vlastimi! > If you have another concern, feel free to say. I don't for now :) [...] > Cc: Rik van Riel <riel at redhat.com> > Cc: Vlastimil Babka <vbabka at suse.cz> > Cc: Joonsoo Kim <iamjoonsoo.kim at lge.com> > Cc: Mel Gorman

On (06/16/16 13:47), Minchan Kim wrote: [..] > > this is what I'm getting with the [zsmalloc: keep first object offset in struct page] > > applied: "count:0 mapcount:-127". which may be not related to zsmalloc at this point. > > > > kernel: BUG: Bad page state in process khugepaged pfn:101db8 > > kernel: page:ffffea0004076e00 count:0 mapcount:-127

On (06/16/16 15:47), Minchan Kim wrote: > > [..] > > > > this is what I'm getting with the [zsmalloc: keep first object offset in struct page] > > > > applied: "count:0 mapcount:-127". which may be not related to zsmalloc at this point. > > > > > > > > kernel: BUG: Bad page state in process khugepaged pfn:101db8 > > >