Re: How cma allocation works ?
On Mon, Aug 26, 2019 at 12:55 PM Michal Hocko wrote: > > On Fri 23-08-19 00:17:22, Pankaj Suryawanshi wrote: > > On Thu, Aug 22, 2019 at 6:32 PM Michal Hocko wrote: > > > > > > On Wed 21-08-19 22:58:03, Pankaj Suryawanshi wrote: > > > > Hello, > > > > > > > > Hard time to understand cma allocation how differs from normal > > > > allocation ? > > > > > > The buddy allocator which is built for order-N sized allocations and it > > > is highly optimized because it used from really hot paths. The allocator > > > also involves memory reclaim to get memory when there is none > > > immediatelly available. > > > > > > CMA allocator operates on a pre reserved physical memory range(s) and > > > focuses on allocating areas that require physically contigous memory of > > > larger sizes. Very broadly speaking. LWN usually contains nice writeups > > > for many kernel internals. E.g. quick googling pointed to > > > https://lwn.net/Articles/486301/ > > > > > > > I know theoretically how cma works. > > > > > > > > 1. How it reserved the memory (start pfn to end pfn) ? what is bitmap_* > > > > functions ? > > > > > > Not sure what you are asking here TBH > > I know it reserved memory at boot time from start pfn to end pfn, but when > > i am requesting memory from cma it has different bitmap_*() in cma_alloc() > > what they are ? > > because we pass pfn and pfn+count to alloc_contig_range and pfn is come > > from bitmap_*() function. > > lets say i have reserved 100MB cma memory at boot time (strart pfn to end > > pfn) and i am requesting allocation of 30MB from cma area then what is pfn > > passed to alloc_contig_range() it is same as start pfn or > > different.(calucaled by bitmap_*()) ? > > I am not deeply familiar with the CMA implementation but from a very > brief look it seems that the bitmap simply denotes which portions of the > reserved area are used and therefore it is easy to find portions of the > requested size by scanning it. > okay > > > Have you checked the code? It simply tries to reclaim and/or migrate > > > pages off the pfn range. > > > > > What is difference between migration, isolation and reclamation of pages ? > > Isolation will set the migrate type to MIGRATE_ISOLATE, btw the comment > in the code I referred to says this: > * Making page-allocation-type to be MIGRATE_ISOLATE means free pages in > * the range will never be allocated. Any free pages and pages freed in the > * future will not be allocated again. If specified range includes migrate > types > * other than MOVABLE or CMA, this will fail with -EBUSY. For isolating all > * pages in the range finally, the caller have to free all pages in the range. > * test_page_isolated() can be used for test it. > > Reclaim part will simply drop all pages that are easily reclaimable > (e.g. a clean pagecache) and migration will move existing allocations to > a different physical location + update references to it from other data > structures (e.g. page tables to point to a new location). Okay Thanks michal, now it will easy to understand. > > > > > > > 5.what isolate_migratepages_range(), reclaim_clean_pages_from_list(), > > > > migrate_pages() and shrink_page_list() is doing ? > > > > > > Again, have you checked the code/comments? What exactly is not clear? > > > > > Why again migrate_isolate_range() ? > > (reclaim_clean_pages_fron_list) if we are reclaiming only clean pages then > > pages will not contiguous ? we have only clean pages which are not > > contiguous ? > > reclaim_clean_pages_from_list is a simple wrapper on top of shrink_page_list. > It simply takes clean page cache pages to reclaim it because that might > be less expensive than migrating that memory. > okay > > What is work of shrink_page_list() ? > > This is a core of the memory reclaim. It unmaps/frees pages and try to > free them. > okay > > please explain all flow with taking > > one allocation for example let say reserved cma 100MB and then request > > allocation of 30MB then how all the flow/function will work ? > > I would recommend to read the code carefully and following the git > history of the code is very helpful as well. This is not a rocket > science, really. hahaha rocket science !!! I think linux memory management should be part of rocket science. > > -- > Michal Hocko > SUSE Labs
Re: PageBlocks and Migrate Types
On Thu, Aug 22, 2019 at 6:22 PM Michal Hocko wrote: > > On Wed 21-08-19 22:23:44, Pankaj Suryawanshi wrote: > > Hello, > > > > 1. What are Pageblocks and migrate types(MIGRATE_CMA) in Linux memory ? > > Pageblocks are a simple grouping of physically contiguous pages with > common set of flags. I haven't checked closely recently so I might > misremember but my recollection is that only the migrate type is stored > there. Normally we would store that information into page flags but > there is not enough room there. > > MIGRATE_CMA represent pages allocated for the CMA allocator. There are > other migrate types denoting unmovable/movable allocations or pages that > are isolated from the page allocator. > > Very broadly speaking, the migrate type groups pages with similar > movability properties to reduce fragmentation that compaction cannot > do anything about because there are objects of different properti > around. Please note that pageblock might contain objects of a different > migrate type in some cases (e.g. low on memory). > > Have a look at gfpflags_to_migratetype and how the gfp mask is converted > to a migratetype for the allocation. Also follow different MIGRATE_$TYPE > to see how it is used in the code. > > > How many movable/unmovable pages are defined by default? > > There is nothing like that. It depends on how many objects of a specific > type are allocated. It means that it started creating pageblocks after allocation of different objects, but from which block it allocate initially when there is nothing like pageblocks ? (when memory subsystem up) Pageblocks and its type dynamically changes ? > > > HTH > -- > Michal Hocko > SUSE Labs
Re: oom-killer
On Tue, Aug 6, 2019 at 8:37 PM Michal Hocko wrote: > > On Tue 06-08-19 20:24:03, Pankaj Suryawanshi wrote: > > On Tue, 6 Aug, 2019, 1:46 AM Michal Hocko, wrote: > > > > > > On Mon 05-08-19 21:04:53, Pankaj Suryawanshi wrote: > > > > On Mon, Aug 5, 2019 at 5:35 PM Michal Hocko wrote: > > > > > > > > > > On Mon 05-08-19 13:56:20, Vlastimil Babka wrote: > > > > > > On 8/5/19 1:24 PM, Michal Hocko wrote: > > > > > > >> [ 727.954355] CPU: 0 PID: 56 Comm: kworker/u8:2 Tainted: P > > > > > > >> O 4.14.65 #606 > > > > > > > [...] > > > > > > >> [ 728.029390] [] (oom_kill_process) from [] > > > > > > >> (out_of_memory+0x140/0x368) > > > > > > >> [ 728.037569] r10:0001 r9:c12169bc r8:0041 r7:c121e680 > > > > > > >> r6:c1216588 r5:dd347d7c > [ 728.045392] r4:d5737080 > > > > > > >> [ 728.047929] [] (out_of_memory) from [] > > > > > > >> (__alloc_pages_nodemask+0x1178/0x124c) > > > > > > >> [ 728.056798] r7:c141e7d0 r6:c12166a4 r5: r4:1155 > > > > > > >> [ 728.062460] [] (__alloc_pages_nodemask) from > > > > > > >> [] (copy_process.part.5+0x114/0x1a28) > > > > > > >> [ 728.071764] r10: r9:dd358000 r8: r7:c1447e08 > > > > > > >> r6:c1216588 r5:00808111 > > > > > > >> [ 728.079587] r4:d1063c00 > > > > > > >> [ 728.082119] [] (copy_process.part.5) from > > > > > > >> [] (_do_fork+0xd0/0x464) > > > > > > >> [ 728.090034] r10: r9: r8:dd008400 r7: > > > > > > >> r6:c1216588 r5:d2d58ac0 > > > > > > >> [ 728.097857] r4:00808111 > > > > > > > > > > > > > > The call trace tells that this is a fork (of a usermodhlper but > > > > > > > that is > > > > > > > not all that important. > > > > > > > [...] > > > > > > >> [ 728.260031] DMA free:17960kB min:16384kB low:25664kB > > > > > > >> high:29760kB active_anon:3556kB inactive_anon:0kB > > > > > > >> active_file:280kB inactive_file:28kB unevictable:0kB > > > > > > >> writepending:0kB present:458752kB managed:422896kB mlocked:0kB > > > > > > >> kernel_stack:6496kB pagetables:9904kB bounce:0kB free_pcp:348kB > > > > > > >> local_pcp:0kB free_cma:0kB > > > > > > >> [ 728.287402] lowmem_reserve[]: 0 0 579 579 > > > > > > > > > > > > > > So this is the only usable zone and you are close to the min > > > > > > > watermark > > > > > > > which means that your system is under a serious memory pressure > > > > > > > but not > > > > > > > yet under OOM for order-0 request. The situation is not great > > > > > > > though > > > > > > > > > > > > Looking at lowmem_reserve above, wonder if 579 applies here? What > > > > > > does > > > > > > /proc/zoneinfo say? > > > > > > > > > > > > What is lowmem_reserve[]: 0 0 579 579 ? > > > > > > This controls how much of memory from a lower zone you might an > > > allocation request for a higher zone consume. E.g. __GFP_HIGHMEM is > > > allowed to use both lowmem and highmem zones. It is preferable to use > > > highmem zone because other requests are not allowed to use it. > > > > > > Please see __zone_watermark_ok for more details. > > > > > > > > > > > This is GFP_KERNEL request essentially so there shouldn't be any > > > > > lowmem > > > > > reserve here, no? > > > > > > > > > > > > Why only low 1G is accessible by kernel in 32-bit system ? > > > > > > 1G ivirtual or physical memory (I have 2GB of RAM) ? > > virtual > I have set 2G/2G still it works ? > > > > https://www.kernel.org/doc/gorman/, https://lwn.net/Articles/75174/ > > > and many more articles. In very short, the 32b virtual address space > > > is quite small and it has to cover both the users space and the > > > kernel. That is why we do split it into 3G reserved for userspace and 1G > > > for kernel. Kernel can only access its 1G portion directly everything > > > else has to be mapped explicitly (e.g. while data is copied). > > > Thanks Michal. > > > > > > > > > > > My system configuration is :- > > > > 3G/1G - vmsplit > > > > vmalloc = 480M (I think vmalloc size will set your highmem ?) > > > > > > No, vmalloc is part of the 1GB kernel adress space. > > > > I read in one article , vmalloc end is fixed if you increase vmalloc > > size it decrease highmem. ? > > Total = lowmem + (vmalloc + high mem) > > As the kernel is using vmalloc area _directly_ then it has to be a part > of the kernel address space - thus reducing the lowmem. > -- > Michal Hocko > SUSE Labs
Re: oom-killer
On Tue, 6 Aug, 2019, 1:46 AM Michal Hocko, wrote: > > On Mon 05-08-19 21:04:53, Pankaj Suryawanshi wrote: > > On Mon, Aug 5, 2019 at 5:35 PM Michal Hocko wrote: > > > > > > On Mon 05-08-19 13:56:20, Vlastimil Babka wrote: > > > > On 8/5/19 1:24 PM, Michal Hocko wrote: > > > > >> [ 727.954355] CPU: 0 PID: 56 Comm: kworker/u8:2 Tainted: P > > > > >> O 4.14.65 #606 > > > > > [...] > > > > >> [ 728.029390] [] (oom_kill_process) from [] > > > > >> (out_of_memory+0x140/0x368) > > > > >> [ 728.037569] r10:0001 r9:c12169bc r8:0041 r7:c121e680 > > > > >> r6:c1216588 r5:dd347d7c > [ 728.045392] r4:d5737080 > > > > >> [ 728.047929] [] (out_of_memory) from [] > > > > >> (__alloc_pages_nodemask+0x1178/0x124c) > > > > >> [ 728.056798] r7:c141e7d0 r6:c12166a4 r5: r4:1155 > > > > >> [ 728.062460] [] (__alloc_pages_nodemask) from > > > > >> [] (copy_process.part.5+0x114/0x1a28) > > > > >> [ 728.071764] r10: r9:dd358000 r8: r7:c1447e08 > > > > >> r6:c1216588 r5:00808111 > > > > >> [ 728.079587] r4:d1063c00 > > > > >> [ 728.082119] [] (copy_process.part.5) from [] > > > > >> (_do_fork+0xd0/0x464) > > > > >> [ 728.090034] r10: r9: r8:dd008400 r7: > > > > >> r6:c1216588 r5:d2d58ac0 > > > > >> [ 728.097857] r4:00808111 > > > > > > > > > > The call trace tells that this is a fork (of a usermodhlper but that > > > > > is > > > > > not all that important. > > > > > [...] > > > > >> [ 728.260031] DMA free:17960kB min:16384kB low:25664kB high:29760kB > > > > >> active_anon:3556kB inactive_anon:0kB active_file:280kB > > > > >> inactive_file:28kB unevictable:0kB writepending:0kB present:458752kB > > > > >> managed:422896kB mlocked:0kB kernel_stack:6496kB pagetables:9904kB > > > > >> bounce:0kB free_pcp:348kB local_pcp:0kB free_cma:0kB > > > > >> [ 728.287402] lowmem_reserve[]: 0 0 579 579 > > > > > > > > > > So this is the only usable zone and you are close to the min watermark > > > > > which means that your system is under a serious memory pressure but > > > > > not > > > > > yet under OOM for order-0 request. The situation is not great though > > > > > > > > Looking at lowmem_reserve above, wonder if 579 applies here? What does > > > > /proc/zoneinfo say? > > > > > > What is lowmem_reserve[]: 0 0 579 579 ? > > This controls how much of memory from a lower zone you might an > allocation request for a higher zone consume. E.g. __GFP_HIGHMEM is > allowed to use both lowmem and highmem zones. It is preferable to use > highmem zone because other requests are not allowed to use it. > > Please see __zone_watermark_ok for more details. > > > > > This is GFP_KERNEL request essentially so there shouldn't be any lowmem > > > reserve here, no? > > > > > > Why only low 1G is accessible by kernel in 32-bit system ? 1G ivirtual or physical memory (I have 2GB of RAM) ? > > > https://www.kernel.org/doc/gorman/, https://lwn.net/Articles/75174/ > and many more articles. In very short, the 32b virtual address space > is quite small and it has to cover both the users space and the > kernel. That is why we do split it into 3G reserved for userspace and 1G > for kernel. Kernel can only access its 1G portion directly everything > else has to be mapped explicitly (e.g. while data is copied). > Thanks Michal. > > > My system configuration is :- > > 3G/1G - vmsplit > > vmalloc = 480M (I think vmalloc size will set your highmem ?) > > No, vmalloc is part of the 1GB kernel adress space. I read in one article , vmalloc end is fixed if you increase vmalloc size it decrease highmem. ? Total = lowmem + (vmalloc + high mem) > > > -- > Michal Hocko > SUSE Labs
Re: oom-killer
On Mon, Aug 5, 2019 at 5:35 PM Michal Hocko wrote: > > On Mon 05-08-19 13:56:20, Vlastimil Babka wrote: > > On 8/5/19 1:24 PM, Michal Hocko wrote: > > >> [ 727.954355] CPU: 0 PID: 56 Comm: kworker/u8:2 Tainted: P O > > >> 4.14.65 #606 > > > [...] > > >> [ 728.029390] [] (oom_kill_process) from [] > > >> (out_of_memory+0x140/0x368) > > >> [ 728.037569] r10:0001 r9:c12169bc r8:0041 r7:c121e680 > > >> r6:c1216588 r5:dd347d7c > [ 728.045392] r4:d5737080 > > >> [ 728.047929] [] (out_of_memory) from [] > > >> (__alloc_pages_nodemask+0x1178/0x124c) > > >> [ 728.056798] r7:c141e7d0 r6:c12166a4 r5: r4:1155 > > >> [ 728.062460] [] (__alloc_pages_nodemask) from [] > > >> (copy_process.part.5+0x114/0x1a28) > > >> [ 728.071764] r10: r9:dd358000 r8: r7:c1447e08 > > >> r6:c1216588 r5:00808111 > > >> [ 728.079587] r4:d1063c00 > > >> [ 728.082119] [] (copy_process.part.5) from [] > > >> (_do_fork+0xd0/0x464) > > >> [ 728.090034] r10: r9: r8:dd008400 r7: > > >> r6:c1216588 r5:d2d58ac0 > > >> [ 728.097857] r4:00808111 > > > > > > The call trace tells that this is a fork (of a usermodhlper but that is > > > not all that important. > > > [...] > > >> [ 728.260031] DMA free:17960kB min:16384kB low:25664kB high:29760kB > > >> active_anon:3556kB inactive_anon:0kB active_file:280kB > > >> inactive_file:28kB unevictable:0kB writepending:0kB present:458752kB > > >> managed:422896kB mlocked:0kB kernel_stack:6496kB pagetables:9904kB > > >> bounce:0kB free_pcp:348kB local_pcp:0kB free_cma:0kB > > >> [ 728.287402] lowmem_reserve[]: 0 0 579 579 > > > > > > So this is the only usable zone and you are close to the min watermark > > > which means that your system is under a serious memory pressure but not > > > yet under OOM for order-0 request. The situation is not great though > > > > Looking at lowmem_reserve above, wonder if 579 applies here? What does > > /proc/zoneinfo say? What is lowmem_reserve[]: 0 0 579 579 ? $cat /proc/sys/vm/lowmem_reserve_ratio 256 32 32 $cat /proc/sys/vm/min_free_kbytes 16384 here is cat /proc/zoneinfo (in normal situation not when oom) $cat /proc/zoneinfo Node 0, zone DMA per-node stats nr_inactive_anon 120 nr_active_anon 94870 nr_inactive_file 101188 nr_active_file 74656 nr_unevictable 614 nr_slab_reclaimable 12489 nr_slab_unreclaimable 8519 nr_isolated_anon 0 nr_isolated_file 0 workingset_refault 7163 workingset_activate 7163 workingset_nodereclaim 0 nr_anon_pages 94953 nr_mapped109148 nr_file_pages 176502 nr_dirty 0 nr_writeback 0 nr_writeback_temp 0 nr_shmem 166 nr_shmem_hugepages 0 nr_shmem_pmdmapped 0 nr_anon_transparent_hugepages 0 nr_unstable 0 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_dirtied 7701 nr_written 6978 pages free 49492 min 4096 low 6416 high 7440 spanned 131072 present 114688 managed 105724 protection: (0, 0, 1491, 1491) nr_free_pages 49492 nr_zone_inactive_anon 0 nr_zone_active_anon 0 nr_zone_inactive_file 65 nr_zone_active_file 4859 nr_zone_unevictable 0 nr_zone_write_pending 0 nr_mlock 0 nr_page_table_pages 4352 nr_kernel_stack 9056 nr_bounce0 nr_zspages 0 nr_free_cma 0 pagesets cpu: 0 count: 16 high: 186 batch: 31 vm stats threshold: 18 cpu: 1 count: 138 high: 186 batch: 31 vm stats threshold: 18 cpu: 2 count: 156 high: 186 batch: 31 vm stats threshold: 18 cpu: 3 count: 170 high: 186 batch: 31 vm stats threshold: 18 node_unreclaimable: 0 start_pfn: 131072 node_inactive_ratio: 0 Node 0, zone Normal pages free 0 min 0 low 0 high 0 spanned 0 present 0 managed 0 protection: (0, 0, 11928, 11928) Node 0, zone HighMem pages free 63096 min 128 low 8506 high 12202 spanned 393216 present 381696 managed 381696 protection: (0, 0, 0, 0) nr_free_pages 63096 nr_zone_inactive_anon 120 nr_zone_active_anon 94863 nr_zone_inactive_file 101123 nr_zone_active_file 69797 nr_zone_unevictable 614 nr_zone_write_pending 0 nr_mlock 614 nr_page_table_pages 1478 nr_kernel_stack 0 nr_bounce0 nr_zspages 0 nr_free_cma 62429 pagesets cpu: 0 count: 30 high: 186 batch: 31 vm stats threshold: 30 cpu: 1 count: 13
Re: Page Allocation Failure and Page allocation stalls
On Mon, May 6, 2019 at 2:35 PM Vlastimil Babka wrote: > > On 5/3/19 7:44 PM, Pankaj Suryawanshi wrote: > >> First possibility that comes to mind is that a usermodehelper got > >> launched, and > >> it then tried to fork with a very large active process image. Do we have > >> any > >> clues what was going on? Did a device get hotplugged? > > > > Yes,The system is android and it tries to allocate memory for video > > player from CMA reserved memory using custom octl call for dma apis. > > The stacktrace doesn't look like a CMA allocation though. That would be > doing alloc_contig_range(), not kmalloc(). Could be some CMA area setup > issue? > I know cma uses alloc_contig_range() but using dma api it will uses many functions. the failure is coming from dma_common_contiguous_remap() for kmalloc , and which is called by dma_alloc_attr for cma allocation. Please let me know, how to avoid page allocation stalls. any reason ? Cpu Utilization issue ? or I am running out of memory ? My System configuration is 2GB RAM Memory Spilt 2G/2G vmalloc=1024M CMA=1024 Max contiguous memory required 390M > > Please let me know how to overcome this issues, or how to reduce > > fragmentation of memory so that higher order allocation get suuceed ? > > > > Thanks > > >
Re: Page Allocation Failure and Page allocation stalls
On Thu, May 2, 2019 at 10:51 AM Valdis Klētnieks wrote: > > On Thu, 02 May 2019 04:56:05 +0530, Pankaj Suryawanshi said: > > > Please help me to decode the error messages and reason for this errors. > > > [ 3205.818891] HwBinder:1894_6: page allocation failure: order:7, > > mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null) > > Order 7 - so it wants 2**7 contiguous pages. 128 4K pages. > kmalloc fails to allocate 2**7 > > [ 3205.967748] [<802186cc>] (__alloc_from_contiguous) from [<80218854>] > > (cma_allocator_alloc+0x44/0x4c) > > And that 3205.nnn tells me the system has been running for almost an hour. > Going > to be hard finding that much contiguous free memory. > > Usually CMA is called right at boot to avoid this problem - why is this > triggering so late? > The use case for late triggering is someone try to play video after an hour, and video memory from CMA area, maybe its due to fragmentation. > > [ 671.925663] kworker/u8:13: page allocation stalls for 10090ms, order:1, > > mode:0x15080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null) > > That's a *really* long stall. > Yes very long any pointers to block this warnings/errors. > > [ 672.031702] [<8021e800>] (copy_process.part.5) from [<802203b0>] > > (_do_fork+0xd0/0x464) > > [ 672.039617] r10: r9: r8:9d008400 r7: > > r6:81216588 r5:9b62f840 > > [ 672.047441] r4:00808111 > > [ 672.049972] [<802202e0>] (_do_fork) from [<802207a4>] > > (kernel_thread+0x38/0x40) > > [ 672.057281] r10: r9:81422554 r8:9d008400 r7: > > r6:9d004500 r5:9b62f840 > > [ 672.065105] r4:81216588 > > [ 672.067642] [<8022076c>] (kernel_thread) from [<802399b4>] > > (call_usermodehelper_exec_work+0x44/0xe0) > > First possibility that comes to mind is that a usermodehelper got launched, > and > it then tried to fork with a very large active process image. Do we have any > clues what was going on? Did a device get hotplugged? Yes,The system is android and it tries to allocate memory for video player from CMA reserved memory using custom octl call for dma apis. Please let me know how to overcome this issues, or how to reduce fragmentation of memory so that higher order allocation get suuceed ? Thanks
Re: vmscan.c: Reclaim unevictable pages.
On Wed, Apr 17, 2019 at 5:12 PM Vlastimil Babka wrote: > > On 4/6/19 7:59 AM, Pankaj Suryawanshi wrote: > > Hello , > > > > shrink_page_list() returns , number of pages reclaimed, when pages is > > unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) || > > PageUnevicatble(page),page); > > > > We can add the unevictable pages in reclaim list in > > shrink_page_list(), return total number of reclaim pages including > > unevictable pages, let the caller handle unevictable pages. > > > > I think the problem is shrink_page_list is awkard. If page is > > unevictable it goto activate_locked->keep_locked->keep lables, keep > > lable list_add the unevictable pages and throw the VM_BUG instead of > > passing it to caller while it relies on caller for > > non-reclaimed-non-unevictable page's putback. > > I think we can make it consistent so that shrink_page_list could > > return non-reclaimed pages via page_list and caller can handle it. As > > an advance, it could try to migrate mlocked pages without retrial. > > > > > > Below is the issue i observed of CMA_ALLOC of large size buffer : > > (Kernel version - 4.14.65 With Android Pie. > > > > [ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || > > PageUnevictable(page)) > > [ 24.726949] page->mem_cgroup:bd008c00 > > [ 24.730693] [ cut here ] > > [ 24.735304] kernel BUG at mm/vmscan.c:1350! > > [ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM > > Please include full report including the full stacktrace, kernel version > etc etc. As mention above kernel version- 4.14.65 for Android pie. Memory Configuration: RAM= 2GB, No swaps CMA reserved = 1GB Max CMA chunk allocation at one time is 400MB and 400MB Full stacktrace is as below. [ 35.301071] cma_alloc: cma alloc try name(video) size(0x17c0) [ 35.312528] page:bf05febc count:55 mapcount:53 mapping:bc8241dc index:0x0 [ 35.319405] flags: 0x8019040c(referenced|uptodate|arch_1|mappedtodisk|unevictable|mlocked) [ 35.327682] raw: 8019040c bc8241dc 0034 0037 b9c6fa98 b9c6fa98 [ 35.335981] raw: bd008c00 [ 35.339145] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page)) [ 35.348402] page->mem_cgroup:bd008c00 [ 35.353531] [ cut here ] [ 35.358155] kernel BUG at mm/vmscan.c:1350! [ 35.362345] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 35.368185] Modules linked in: vpu_4k_d2_dev jpu_dev vpu vpu_4k_d2_lib_arm_v4_14(PO) jpu_c6_lib_arm_v4_14(PO) vpu_d6_lib_arm_v4_14(PO) [ 35.380303] CPU: 1 PID: 3710 Comm: HwBinder:1888_3 Tainted: P O4.14.65-tcc #120 [ 35.388823] Hardware name: Android (Flattened Device Tree) [ 35.395182] task: bdd4f080 task.stack: b9c6e000 [ 35.399728] PC is at shrink_page_list+0x448/0x106c [ 35.404521] LR is at irq_work_queue+0xc0/0xd4 [ 35.408882] pc : [<80360a58>]lr : [<80313548>]psr: 60070013 [ 35.415147] sp : b9c6fa48 ip : b9c6f8b0 fp : b9c6fafc [ 35.420364] r10: r9 : bc8666fc r8 : b9c6fb0c [ 35.425581] r7 : b9c6fb14 r6 : 0001 r5 : bf05febc r4 : bf05fed0 [ 35.432101] r3 : 5725f132 r2 : 5725f132 r1 : be57a4f4 r0 : 0019 [ 35.438622] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 35.445751] Control: 30c5383d Table: 5b1dce00 DAC: [ 35.451488] [ 35.451488] PC: 0x803609d8: [ 35.455750] 09d8 [ 35.455753] ee1d1f90 [ 35.457671] e28330c8 [ 35.459934] e7912003 [ 35.462197] e2822001 [ 35.464460] e7812003 [ 35.466723] e121f000 [ 35.468986] e1a5 [ 35.471249] ebff8a31 [ 35.473512] [ 35.477254] 09f8 [ 35.477256] e51b3064 [ 35.479172] e24b2064 [ 35.481435] e5834004 [ 35.483699] e5843000 [ 35.485961] e50b4064 [ 35.488224] e5943000 [ 35.490489] e5842004 [ 35.492752] e3130001 [ 35.495015] [ 35.498759] 0a18 [ 35.498762] 12433001 [ 35.500678] 01a03005 [ 35.502943] e5933000 [ 35.505205] e3130020 [ 35.507469] 1a06 [ 35.509732] e5943000 [ 35.511995] e3130001 [ 35.514258] 12433001 [ 35.516521] [ 35.520262] 0a38 [ 35.520264] 01a03005 [ 35.522180] e5933000 [ 35.52] e3130702 [ 35.526707] 0a1b [ 35.528970] e30a13f8 [ 35.531233] e1a5 [ 35.533496] e34810e0 [ 35.535759] eb0074a8 [ 35.538021] [ 35.541763] 0a58 [ 35.541766] e7f001f2 [ 35.543681] e350 [ 35.545944] 0a12 [ 35.548207] e599 [ 35.550470] e350 [ 35.552733] 0a96 [ 35.554996] e3063b04 [ 35.557260] e590201c [ 35.559523] [ 35.563265] 0a78 [ 35.563267] e3483121 [ 35.565183] e5933000 [ 35.567446] e1520003 [ 35.569709] 1592108c [ 35.571972] 0a000260 [ 35.574237] e5912038 [ 35.576500] e5923010 [ 35.578
Re: [External] Re: Basics : Memory Configuration
From: Christopher Lameter Sent: 09 April 2019 21:31 To: Pankaj Suryawanshi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: [External] Re: Basics : Memory Configuration On Tue, 9 Apr 2019, Pankaj Suryawanshi wrote: > I am confuse about memory configuration and I have below questions Hmmm... Yes some of the terminology that you use is a bit confusing. > 1. if 32-bit os maximum virtual address is 4GB, When i have 4 gb of ram > for 32-bit os, What about the virtual memory size ? is it required > virtual memory(disk space) or we can directly use physical memory ? The virtual memory size is the maximum virtual size of a single process. Multiple processes can run and each can use different amounts of physical memory. So both are actually independent. Okay Got it. The size of the virtual memory space per process is configurable on x86 32 bit (2G, 3G, 4G). Thus the possible virtual process size may vary depending on the hardware architecture and the configuration of the kernel. Another Questions - - Q. If i configures VMSPLIT = 2G/2G what does it mean ? - Q. Disk Space is used by Virtual Memory ? If this is true, than without secondary storage there is no virtual memory ? let say for 32-bit os i have 4GB ram than what is the use case of virtual memory ? > 2. In 32-bit os 12 bits are offset because page size=4k i.e 2^12 and > 2^20 for page addresses >What about 64-bit os, What is offset size ? What is page size ? How it > calculated. 12 bits are passed through? Thats what you mean? The remainder of the bits are used to lookup the physical frame number(PFN) in the page tables. 64 bit is the same. However, the number of bits used for lookups in the page tables are much higher. - Q. for 32-bit os page size is 4k, what is the page size for 64-bit os ? page size and offset is related to each other ? - Q. if i increase the page size from 4k to 8k, does it change the offset size that it 2^12 to 2^13 ? - Q. Why only 48 bits are used in 64-bit os ? > 3. What is PAE? If enabled how to decide size of PAE, what is maximum > and minimum size of extended memory. PAE increases the physical memory size that can be addressed through a page table lookup. The number of bits that can be specified in the PFN is increased and thus more than 4GB of physical memory can be used by the operating system. However, the virtual memory size stays the same and an individual process still cannot use more memory. - Q. Let say i enabled PAE for 32-bit os with 6GB ram.Virtual size is same 4GB, 32-bit os cant address more thatn 4gb, Than what is the use of 6GB with PAE enabled. * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: Basics : Memory Configuration
From: Christopher Lameter Sent: 09 April 2019 21:31 To: Pankaj Suryawanshi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: [External] Re: Basics : Memory Configuration On Tue, 9 Apr 2019, Pankaj Suryawanshi wrote: > I am confuse about memory configuration and I have below questions Hmmm... Yes some of the terminology that you use is a bit confusing. > 1. if 32-bit os maximum virtual address is 4GB, When i have 4 gb of ram > for 32-bit os, What about the virtual memory size ? is it required > virtual memory(disk space) or we can directly use physical memory ? The virtual memory size is the maximum virtual size of a single process. Multiple processes can run and each can use different amounts of physical memory. So both are actually independent. The size of the virtual memory space per process is configurable on x86 32 bit (2G, 3G, 4G). Thus the possible virtual process size may vary depending on the hardware architecture and the configuration of the kernel. If i have configures VMSPLIT = 2G/2G what does it mean ? Virtual memory uses disk space ? let say for 32-bit os i have 4GB ram than what is the use case of virtual memory ? If i have 32-bit and 2gb/3gb ram than virtual memory is useful because its less than 4GB ? > 2. In 32-bit os 12 bits are offset because page size=4k i.e 2^12 and > 2^20 for page addresses >What about 64-bit os, What is offset size ? What is page size ? How it > calculated. 12 bits are passed through? Thats what you mean? The remainder of the bits are used to lookup the physical frame number(PFN) in the page tables. 64 bit is the same. However, the number of bits used for lookups in the page tables are much higher. for 32-bit os page size is 4k, what is the page size for 64-bit os ? page size and offset is related to each other ? if i increase the page size from 4k to 8k, does it change the offset size that it 2^12 to 2^13 ? Why only 48 bits are used in 64-bit os ? > 3. What is PAE? If enabled how to decide size of PAE, what is maximum > and minimum size of extended memory. PAE increases the physical memory size that can be addressed through a page table lookup. The number of bits that can be specified in the PFN is increased and thus more than 4GB of physical memory can be used by the operating system. However, the virtual memory size stays the same and an individual process still cannot use more memory. Let say i have ,enabled PAE for 32-bit os with 6GB ram.Virtual size is same 4GB, 32-bit os cant address more thatn 4gb, Than what is the use of 6GB with PAE enabled. * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Basics : Memory Configuration
Hello, I am confuse about memory configuration and I have below questions 1. if 32-bit os maximum virtual address is 4GB, When i have 4 gb of ram for 32-bit os, What about the virtual memory size ? is it required virtual memory(disk space) or we can directly use physical memory ? 2. In 32-bit os 12 bits are offset because page size=4k i.e 2^12 and 2^20 for page addresses What about 64-bit os, What is offset size ? What is page size ? How it calculated. 3. What is PAE? If enabled how to decide size of PAE, what is maximum and minimum size of extended memory. Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: CMA area pages information
From: Shyam Saini Sent: 04 April 2019 19:58 To: Pankaj Suryawanshi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: [External] Re: CMA area pages information CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, Apr 4, 2019 at 7:52 PM Pankaj Suryawanshi mailto:pankaj.suryawan...@einfochips.com>> wrote: From: Pankaj Suryawanshi Sent: 01 April 2019 16:34 To: linux-kernel@vger.kernel.org<mailto:linux-kernel@vger.kernel.org>; linux...@kvack.org<mailto:linux...@kvack.org> Subject: Re: CMA area pages information ____ From: Pankaj Suryawanshi Sent: 01 April 2019 13:26 To: linux-kernel@vger.kernel.org<mailto:linux-kernel@vger.kernel.org>; linux...@kvack.org<mailto:linux...@kvack.org> Subject: CMA area pages information Hello, Is there any way to get CMA area pages information (tool/application) ? Trying to get CMA-pages info using /tools/vm/page-types.c 1. Allocate 100 mb using sample app. 2. Try to get page info using page-types.c. Note: cma base-pfn: 0x6 cma reserved 1026 Mib Pages info i got is ./test -p 3401 -L voffset offset flags 5c1a3 70e92 ___U_lAM__ 5c1a4 73104 ___U_l_M__ 5c1a6 70ad1 ___U_lAMa_b___ 71ea1 9f470 __RU_l_M__u___ 71ea2 9f471 __RU_l_M__u___ 71ea3 9f472 __RU_l_M__u___ 71ea4 9f473 __RU_l_M__u___ 71ea5 9f485 __RU_l_M__u___ 71ea6 9f486 __RU_l_M__u___ 71ea7 9f487 __RU_l_M__u___ 71ea8 9f488 __RU_l_M__u___ 71ea9 9f489 __RU_l_M__u___ 71eaa 9f48a __RU_l_M__u___ 71eab 9f48b __RU_l_M__u___ 71eac 9f48c __RU_l_M__u___ 71ead 9f48d __RU_l_M__u___ 71eae 9f48e __RU_l_M__u___ 71eaf 9f48f __RU_l_M__u___ 71eb0 9f490 __RU_l_M__u___ 71eb1 9f491 __RU_l_M__u___ 71eb2 9f492 __RU_l_M__u___ 71eb3 9f493 __RU_l_M__u___ 71eb4 9f494 __RU_l_M__u___ 71eb5 9f495 __RU_l_M__u___ 71eb6 9f496 __RU_l_M__u___ 71eb7 9f497 __RU_l_M__u___ 71eb8 9f498 __RU_l_M__u___ 71eb9 9f499 __RU_l_M__u___ 71eba 9f49a __RU_l_M__u___ 71ebb 9f49b __RU_l_M__u___ 71ebc 9f49c __RU_l_M__u___ 71ebd 9f49d __RU_l_M__u___ 71ebe 9f49e __RU_l_M__u___ 71ebf 9f49f __RU_l_M__u___ 71ec0 9f4a0 __RU_l_M__u___ 71ec1 9f56b __RU_l_M__u___ 71ec2 9f56c __RU_l_M__u___ 71ec3 9f56d __RU_l_M__u___ 71ec4 9f56e __RU_l_M__u___ 71ec5 9f56f __RU_l_M__u___ 71ec6 9f570 __RU_l_M__u___ 71ec7 9f571 __RU_l_M__u___ 71ec8 9f572 __RU_l_M__u___ 71ec9 9f573 __RU_l_M__u___ 71eca 9f574 __RU_l_M__u___ 71ecb 9f575 __RU_l_M__u___ 71ecc 9f576 __RU_l_M__u___ 71ecd 9f577 __RU_l_M__u___ 71ece 9f578 __RU_l_M__u___ 71ecf 9f579 __RU_l_M__u___ 71ed0 9f57a __RU_l_M__u___ 71ed1 9f57b __RU_l_M__u___ 71ed2 9f57c __RU_l_M__u___ 71ed3 9f5ea __RU_l_M__u___ 71ed4 9f5eb __RU_l_M__u___ 71ed5 9f5ec __RU_l_M__u___ 71ed6 9f5ed __RU_l_M__u___ 71ed7 9f5ee __RU_l_M__u___ 71ed8 9f5ef __RU_l_M__u___ 71ed9 9f5f0 __RU_l_M__u___ 71eda 9f5f1 __RU_l_M__u___ 71edb 9f5f2 __RU_l_M__
Re: CMA area pages information
From: Pankaj Suryawanshi Sent: 01 April 2019 16:34 To: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: Re: CMA area pages information From: Pankaj Suryawanshi Sent: 01 April 2019 13:26 To: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: CMA area pages information Hello, Is there any way to get CMA area pages information (tool/application) ? Trying to get CMA-pages info using /tools/vm/page-types.c 1. Allocate 100 mb using sample app. 2. Try to get page info using page-types.c. Note: cma base-pfn: 0x6 cma reserved 1026 Mib Pages info i got is ./test -p 3401 -L voffset offset flags 5c1a3 70e92 ___U_lAM__ 5c1a4 73104 ___U_l_M__ 5c1a6 70ad1 ___U_lAMa_b___ 71ea1 9f470 __RU_l_M__u___ 71ea2 9f471 __RU_l_M__u___ 71ea3 9f472 __RU_l_M__u___ 71ea4 9f473 __RU_l_M__u___ 71ea5 9f485 __RU_l_M__u___ 71ea6 9f486 __RU_l_M__u___ 71ea7 9f487 __RU_l_M__u___ 71ea8 9f488 __RU_l_M__u___ 71ea9 9f489 __RU_l_M__u___ 71eaa 9f48a __RU_l_M__u___ 71eab 9f48b __RU_l_M__u___ 71eac 9f48c __RU_l_M__u___ 71ead 9f48d __RU_l_M__u___ 71eae 9f48e __RU_l_M__u___ 71eaf 9f48f __RU_l_M__u___ 71eb0 9f490 __RU_l_M__u___ 71eb1 9f491 __RU_l_M__u___ 71eb2 9f492 __RU_l_M__u___ 71eb3 9f493 __RU_l_M__u___ 71eb4 9f494 __RU_l_M__u___ 71eb5 9f495 __RU_l_M__u___ 71eb6 9f496 __RU_l_M__u___ 71eb7 9f497 __RU_l_M__u___ 71eb8 9f498 __RU_l_M__u___ 71eb9 9f499 __RU_l_M__u___ 71eba 9f49a __RU_l_M__u___ 71ebb 9f49b __RU_l_M__u___ 71ebc 9f49c __RU_l_M__u___ 71ebd 9f49d __RU_l_M__u___ 71ebe 9f49e __RU_l_M__u___ 71ebf 9f49f __RU_l_M__u___ 71ec0 9f4a0 __RU_l_M__u___ 71ec1 9f56b __RU_l_M__u___ 71ec2 9f56c __RU_l_M__u___ 71ec3 9f56d __RU_l_M__u___ 71ec4 9f56e __RU_l_M__u___ 71ec5 9f56f __RU_l_M__u___ 71ec6 9f570 __RU_l_M__u___ 71ec7 9f571 __RU_l_M__u___ 71ec8 9f572 __RU_l_M__u___ 71ec9 9f573 __RU_l_M__u___ 71eca 9f574 __RU_l_M__u___ 71ecb 9f575 __RU_l_M__u___ 71ecc 9f576 __RU_l_M__u___ 71ecd 9f577 __RU_l_M__u___ 71ece 9f578 __RU_l_M__u___ 71ecf 9f579 __RU_l_M__u___ 71ed0 9f57a __RU_l_M__u___ 71ed1 9f57b __RU_l_M__u___ 71ed2 9f57c __RU_l_M__u___ 71ed3 9f5ea __RU_l_M__u___ 71ed4 9f5eb __RU_l_M__u___ 71ed5 9f5ec __RU_l_M__u___ 71ed6 9f5ed __RU_l_M__u___ 71ed7 9f5ee __RU_l_M__u___ 71ed8 9f5ef __RU_l_M__u___ 71ed9 9f5f0 __RU_l_M__u___ 71eda 9f5f1 __RU_l_M__u___ 71edb 9f5f2 __RU_l_M__u___ 71edc 9f5f3 __RU_l_M__u___ 71edd 9f5f4 __RU_l_M__u___ 71ede 9f5f5 __RU_l_M__u___ 71edf 9f5f6 __RU_l_M__u___ 71ee0 9f5f7 __RU_l_M__u___ 71ee1 9f5f8 __RU_l_M__u___ 71ee2 9f5f9 __RU_l_M__u___ 71ee3 9f5fa __RU_l_M__u___ 71ee4 9f5fb __RU_l_M__u___ 71ee5 9f5fc __RU_l_M__u___ 71ee6 9f5fd
Re: How to calculate instruction executed for function
From: Pankaj Suryawanshi Sent: 03 April 2019 19:50 To: linux...@kvack.org; linux-kernel@vger.kernel.org Subject: How to calculate instruction executed for function Hello, How to calculate instruction executed for function ? For eg. I need to calculate instruction executed for CMA_ALLOC function. How many instruction executed for cma_alloc ? CMA_ALLOC : for 1 cma_alloc success call there will around 75 instruction is executed, excluding jump, mutex,error case and debug info instruction. below are mandatory jump calls that are required for successful allocations. cma_bitmap_aligned_mask cma_bitmap_aligned_offset cma_bitmap_maxno cma_bitmap_pages_to_bits bitmap_find_next_zero_area_off -> find_next_zero_bit -> find_next_bit bitmap_set alloc_contig_range -> start_isolate_page_range __alloc_contig_migrate_range -> isolate_migratepages_range -> reclaim_clean_pages_from_list -> shrink_page_list -> migrate_pages So lets say cma_bitmap_aligned_mask = 1 instrs cma_bitmap_aligned_offset = 1 instrs cma_bitmap_maxno = 1 instrs cma_bitmap_pages_to_bits = 1 instrs bitmap_find_next_zero_area_off -> find_next_zero_bit -> find_next_bit = 3 instrs bitmap_set = 1 instrs alloc_contig_range -> start_isolate_page_range = has_unmovable_pages = 1 instrs get_pfnblock_flags_mask = 1 instrs set_pageblock_migratetype = 1 instrs move_freepages_block = 1 instrn __mod_zone_page_state = 1 instrs store info in vmstat unset_migratetype_isolate = 1 instrs __alloc_contig_migrate_range -> isolate_migratepages_range -> reclaim_clean_pages_from_list -> shrink_page_list -> migrate_pages isolate_migratepages_range = 3 instrs reclaim_clean_pages_from_list = 2 instrs migrate_pages = 1 instrs -- Total = around 20 instrs per page 20 ns per page on 1ghz processor is minimum excluding any overheads like mutex, variables, failure/error case,debug/prints. I roughly calculated this. Is it Correct ? Any help would be appreciated. Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
How to calculate instruction executed for function
Hello, How to calculate instruction executed for function ? For eg. I need to calculate instruction executed for CMA_ALLOC function. How many instruction executed for cma_alloc ? Any help would be appreciated. Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: CMA area pages information
From: Pankaj Suryawanshi Sent: 01 April 2019 13:26 To: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: CMA area pages information Hello, Is there any way to get CMA area pages information (tool/application) ? Trying to get CMA-pages info using /tools/vm/page-types.c 1. Allocate 100 mb using sample app. 2. Try to get page info using page-types.c. Note: cma base-pfn: 0x6 cma reserved 1026 Mib Pages info i got is ./test -p 3401 -L voffset offset flags 5c1a3 70e92 ___U_lAM__ 5c1a4 73104 ___U_l_M__ 5c1a6 70ad1 ___U_lAMa_b___ 71ea1 9f470 __RU_l_M__u___ 71ea2 9f471 __RU_l_M__u___ 71ea3 9f472 __RU_l_M__u___ 71ea4 9f473 __RU_l_M__u___ 71ea5 9f485 __RU_l_M__u___ 71ea6 9f486 __RU_l_M__u___ 71ea7 9f487 __RU_l_M__u___ 71ea8 9f488 __RU_l_M__u___ 71ea9 9f489 __RU_l_M__u___ 71eaa 9f48a __RU_l_M__u___ 71eab 9f48b __RU_l_M__u___ 71eac 9f48c __RU_l_M__u___ 71ead 9f48d __RU_l_M__u___ 71eae 9f48e __RU_l_M__u___ 71eaf 9f48f __RU_l_M__u___ 71eb0 9f490 __RU_l_M__u___ 71eb1 9f491 __RU_l_M__u___ 71eb2 9f492 __RU_l_M__u___ 71eb3 9f493 __RU_l_M__u___ 71eb4 9f494 __RU_l_M__u___ 71eb5 9f495 __RU_l_M__u___ 71eb6 9f496 __RU_l_M__u___ 71eb7 9f497 __RU_l_M__u___ 71eb8 9f498 __RU_l_M__u___ 71eb9 9f499 __RU_l_M__u___ 71eba 9f49a __RU_l_M__u___ 71ebb 9f49b __RU_l_M__u___ 71ebc 9f49c __RU_l_M__u___ 71ebd 9f49d __RU_l_M__u___ 71ebe 9f49e __RU_l_M__u___ 71ebf 9f49f __RU_l_M__u___ 71ec0 9f4a0 __RU_l_M__u___ 71ec1 9f56b __RU_l_M__u___ 71ec2 9f56c __RU_l_M__u___ 71ec3 9f56d __RU_l_M__u___ 71ec4 9f56e __RU_l_M__u___ 71ec5 9f56f __RU_l_M__u___ 71ec6 9f570 __RU_l_M__u___ 71ec7 9f571 __RU_l_M__u___ 71ec8 9f572 __RU_l_M__u___ 71ec9 9f573 __RU_l_M__u___ 71eca 9f574 __RU_l_M__u___ 71ecb 9f575 __RU_l_M__u___ 71ecc 9f576 __RU_l_M__u___ 71ecd 9f577 __RU_l_M__u___ 71ece 9f578 __RU_l_M__u___ 71ecf 9f579 __RU_l_M__u___ 71ed0 9f57a __RU_l_M__u___ 71ed1 9f57b __RU_l_M__u___ 71ed2 9f57c __RU_l_M__u___ 71ed3 9f5ea __RU_l_M__u___ 71ed4 9f5eb __RU_l_M__u___ 71ed5 9f5ec __RU_l_M__u___ 71ed6 9f5ed __RU_l_M__u___ 71ed7 9f5ee __RU_l_M__u___ 71ed8 9f5ef __RU_l_M__u___ 71ed9 9f5f0 __RU_l_M__u___ 71eda 9f5f1 __RU_l_M__u___ 71edb 9f5f2 __RU_l_M__u___ 71edc 9f5f3 __RU_l_M__u___ 71edd 9f5f4 __RU_l_M__u___ 71ede 9f5f5 __RU_l_M__u___ 71edf 9f5f6 __RU_l_M__u___ 71ee0 9f5f7 __RU_l_M__u___ 71ee1 9f5f8 __RU_l_M__u___ 71ee2 9f5f9 __RU_l_M__u___ 71ee3 9f5fa __RU_l_M__u___ 71ee4 9f5fb __RU_l_M__u___ 71ee5 9f5fc __RU_l_M__u___ 71ee6 9f5fd __RU_l_M__u___ 71ee7 9f5fe __RU_l_M__u___ 71ee8 9f5ff __RU_l_M__u___ 71ee9 9f600
CMA area pages information
Hello, Is there any way to get CMA area pages information (tool/application) ? Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: Print map for total physical and virtual memory
From: Pankaj Suryawanshi Sent: 29 March 2019 10:52 To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: Re: [External] Re: Print map for total physical and virtual memory From: Matthew Wilcox Sent: 26 March 2019 18:13 To: Pankaj Suryawanshi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: Re: [External] Re: Print map for total physical and virtual memory On Tue, Mar 26, 2019 at 12:35:25PM +, Pankaj Suryawanshi wrote: > From: Matthew Wilcox > Sent: 26 March 2019 17:06 > To: Pankaj Suryawanshi > Cc: linux-kernel@vger.kernel.org; linux...@kvack.org > Subject: [External] Re: Print map for total physical and virtual memory > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. ... you should probably use gmail or something. Whatever broken email system your employer provides makes it really hard for you to participate in any meaningful way. Okay i will use gmail. > Can you please elaborate about tools/vm/page-types.c ? cd tools/vm/ make sudo ./page-types If that doesn't do exactly what you need, you can use the source code to make a program which does. Is there any other way to print only cma area pages ? because i am interested for cma area pages only. Thanks Matthew. * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: Page-allocation-failure
From: Pankaj Suryawanshi Sent: 28 March 2019 13:17 To: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: Re: Page-allocation-failure From: Pankaj Suryawanshi Sent: 28 March 2019 13:12 To: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: Page-allocation-failure Hello , I am facing issue related to page allocation failure. If anyone is familiar with this issue, let me know what is the issue? How to solved/debug it. Failure logs -: - [ 45.073877] kswapd0: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null) [ 45.073897] CPU: 1 PID: 716 Comm: kswapd0 Tainted: P O4.14.65 #3 [ 45.073899] Hardware name: Android (Flattened Device Tree) [ 45.073901] Backtrace: [ 45.073915] [<8020dbec>] (dump_backtrace) from [<8020ded0>] (show_stack+0x18/0x1c) [ 45.073920] r6:600f0093 r5:8141bd5c r4: r3:3abdc664 [ 45.073928] [<8020deb8>] (show_stack) from [<80ba5e30>] (dump_stack+0x94/0xa8) [ 45.073936] [<80ba5d9c>] (dump_stack) from [<80350610>] (warn_alloc+0xe0/0x194) [ 45.073940] r6:80e090cc r5: r4:81216588 r3:3abdc664 [ 45.073946] [<80350534>] (warn_alloc) from [<803514e0>] (__alloc_pages_nodemask+0xd70/0x124c) [ 45.073949] r3: r2:80e090cc [ 45.073952] r6:0001 r5: r4:8121696c [ 45.073959] [<80350770>] (__alloc_pages_nodemask) from [<803a6c20>] (allocate_slab+0x364/0x3e4) [ 45.073964] r10:0080 r9: r8:01081220 r7: r6: r5:01080020 [ 45.073966] r4:bd00d180 [ 45.073971] [<803a68bc>] (allocate_slab) from [<803a8c98>] (___slab_alloc.constprop.6+0x420/0x4b8) [ 45.073977] r10: r9: r8:bd00d180 r7:01080020 r6:81216588 r5:be586360 [ 45.073978] r4: [ 45.073984] [<803a8878>] (___slab_alloc.constprop.6) from [<803a8d54>] (__slab_alloc.constprop.5+0x24/0x2c) [ 45.073989] r10:0004e299 r9:bd00d180 r8:01080020 r7:8147b954 r6:bd6e5a68 r5: [ 45.073991] r4:600f0093 [ 45.073996] [<803a8d30>] (__slab_alloc.constprop.5) from [<803a9058>] (kmem_cache_alloc+0x16c/0x2d0) [ 45.073999] r4:bd00d180 r3:be586360 --- [ 44.966861] Mem-Info: [ 44.966872] active_anon:106078 inactive_anon:142 isolated_anon:0 [ 44.966872] active_file:39117 inactive_file:34254 isolated_file:101 [ 44.966872] unevictable:597 dirty:157 writeback:0 unstable:0 [ 44.966872] slab_reclaimable:4967 slab_unreclaimable:9288 [ 44.966872] mapped:60971 shmem:185 pagetables:5905 bounce:0 [ 44.966872] free:2363 free_pcp:334 free_cma:0 [ 44.966879] Node 0 active_anon:424312kB inactive_anon:568kB active_file:156468kB inactive_file:137016kB unevictable:2388kB isolated(anon):0kB isolated(file):404kB mapped:243884kB dirty:628kB writeback:0kB shmem:740kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [ 44.966889] DMA free:9348kB min:3772kB low:15684kB high:16624kB active_anon:420592kB inactive_anon:284kB active_file:155116kB inactive_file:135724kB unevictable:1592kB writepending:628kB present:928768kB managed:892508kB mlocked:1592kB kernel_stack:9304kB pagetables:23440kB bounce:0kB free_pcp:1336kB local_pcp:672kB free_cma:0kB [ 44.966890] lowmem_reserve[]: 0 0 8 8 [ 44.966903] HighMem free:104kB min:128kB low:236kB high:244kB active_anon:2632kB inactive_anon:284kB active_file:1912kB inactive_file:1732kB unevictable:796kB writepending:0kB present:1056768kB managed:8192kB mlocked:796kB kernel_stack:0kB pagetables:180kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 44.966904] lowmem_reserve[]: 0 0 0 0 [ 44.966909] DMA: 148*4kB (UMH) 52*8kB (UMH) 30*16kB (UMH) 19*32kB (MH) 7*64kB (MH) 4*128kB (H) 5*256kB (H) 0*512kB 0*1024kB 1*2048kB (H) 1*4096kB (H) 0*8192kB 0*16384kB = 10480kB [ 44.966936] HighMem: 2*4kB (UM) 2*8kB (UM) 1*16kB (U) 0*32kB 1*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 104kB [ 44.966958] 74134 total pagecache pages [ 44.966961] 0 pages in swap cache [ 44.966963] Swap cache stats: add 0, delete 0, find 0/0 [ 44.966965] Free swap = 0kB [ 44.966966] Total swap = 0kB [ 44.966967] 496384 pages RAM [ 44.966969] 264192 pages HighMem/MovableOnly [ 44.966972] 271209 pages reserved [ 44.966975] 262144 pages cma reserved /proc/sys/vm/min_free_kbytes = 3774 Can increasing this value will solved this issue ? Regards, Pankaj * eInfochip
Re: [External] Re: vmscan: Reclaim unevictable pages
From: Michal Hocko Sent: 26 March 2019 15:06 To: Pankaj Suryawanshi Cc: Kirill Tkhai; Vlastimil Babka; aneesh.ku...@linux.ibm.com; linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; khand...@linux.vnet.ibm.com Subject: Re: [External] Re: vmscan: Reclaim unevictable pages On Tue 26-03-19 09:16:11, Pankaj Suryawanshi wrote: > > > From: Michal Hocko > Sent: 26 March 2019 14:31 > To: Pankaj Suryawanshi > Cc: Kirill Tkhai; Vlastimil Babka; aneesh.ku...@linux.ibm.com; > linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; > khand...@linux.vnet.ibm.com > Subject: Re: [External] Re: vmscan: Reclaim unevictable pages > > [You were asked to use a reasonable quoting several times. This is > really annoying because it turns the email thread into a complete mess] > > [Already fix the email client, but dont know the reason for quoting Maybe > account issue.] You clearly haven't > As i said earlier, i am using vanilla kernel 4.14.65. This got lost in the quoting mess. Can you reproduce with 5.0? Actually i am using android pie-9.0, can i replace kernel 4.14.65 to 5.0 ? -- Michal Hocko SUSE Labs * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: Print map for total physical and virtual memory
From: Matthew Wilcox Sent: 26 March 2019 18:13 To: Pankaj Suryawanshi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: Re: [External] Re: Print map for total physical and virtual memory On Tue, Mar 26, 2019 at 12:35:25PM +, Pankaj Suryawanshi wrote: > From: Matthew Wilcox > Sent: 26 March 2019 17:06 > To: Pankaj Suryawanshi > Cc: linux-kernel@vger.kernel.org; linux...@kvack.org > Subject: [External] Re: Print map for total physical and virtual memory > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. ... you should probably use gmail or something. Whatever broken email system your employer provides makes it really hard for you to participate in any meaningful way. Okay i will use gmail. > Can you please elaborate about tools/vm/page-types.c ? cd tools/vm/ make sudo ./page-types If that doesn't do exactly what you need, you can use the source code to make a program which does. Thanks Matthew. * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: Page-allocation-failure
From: Pankaj Suryawanshi Sent: 28 March 2019 13:12 To: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: Page-allocation-failure Hello , I am facing issue related to page allocation failure. If anyone is familiar with this issue, let me know what is the issue? How to solved/debug it. Failure logs -: - [ 45.073877] kswapd0: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null) [ 45.073897] CPU: 1 PID: 716 Comm: kswapd0 Tainted: P O4.14.65 #3 [ 45.073899] Hardware name: Android (Flattened Device Tree) [ 45.073901] Backtrace: [ 45.073915] [<8020dbec>] (dump_backtrace) from [<8020ded0>] (show_stack+0x18/0x1c) [ 45.073920] r6:600f0093 r5:8141bd5c r4: r3:3abdc664 [ 45.073928] [<8020deb8>] (show_stack) from [<80ba5e30>] (dump_stack+0x94/0xa8) [ 45.073936] [<80ba5d9c>] (dump_stack) from [<80350610>] (warn_alloc+0xe0/0x194) [ 45.073940] r6:80e090cc r5: r4:81216588 r3:3abdc664 [ 45.073946] [<80350534>] (warn_alloc) from [<803514e0>] (__alloc_pages_nodemask+0xd70/0x124c) [ 45.073949] r3: r2:80e090cc [ 45.073952] r6:0001 r5: r4:8121696c [ 45.073959] [<80350770>] (__alloc_pages_nodemask) from [<803a6c20>] (allocate_slab+0x364/0x3e4) [ 45.073964] r10:0080 r9: r8:01081220 r7: r6: r5:01080020 [ 45.073966] r4:bd00d180 [ 45.073971] [<803a68bc>] (allocate_slab) from [<803a8c98>] (___slab_alloc.constprop.6+0x420/0x4b8) [ 45.073977] r10: r9: r8:bd00d180 r7:01080020 r6:81216588 r5:be586360 [ 45.073978] r4: [ 45.073984] [<803a8878>] (___slab_alloc.constprop.6) from [<803a8d54>] (__slab_alloc.constprop.5+0x24/0x2c) [ 45.073989] r10:0004e299 r9:bd00d180 r8:01080020 r7:8147b954 r6:bd6e5a68 r5: [ 45.073991] r4:600f0093 [ 45.073996] [<803a8d30>] (__slab_alloc.constprop.5) from [<803a9058>] (kmem_cache_alloc+0x16c/0x2d0) [ 45.073999] r4:bd00d180 r3:be586360 --- [ 44.966861] Mem-Info: [ 44.966872] active_anon:106078 inactive_anon:142 isolated_anon:0 [ 44.966872] active_file:39117 inactive_file:34254 isolated_file:101 [ 44.966872] unevictable:597 dirty:157 writeback:0 unstable:0 [ 44.966872] slab_reclaimable:4967 slab_unreclaimable:9288 [ 44.966872] mapped:60971 shmem:185 pagetables:5905 bounce:0 [ 44.966872] free:2363 free_pcp:334 free_cma:0 [ 44.966879] Node 0 active_anon:424312kB inactive_anon:568kB active_file:156468kB inactive_file:137016kB unevictable:2388kB isolated(anon):0kB isolated(file):404kB mapped:243884kB dirty:628kB writeback:0kB shmem:740kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [ 44.966889] DMA free:9348kB min:3772kB low:15684kB high:16624kB active_anon:420592kB inactive_anon:284kB active_file:155116kB inactive_file:135724kB unevictable:1592kB writepending:628kB present:928768kB managed:892508kB mlocked:1592kB kernel_stack:9304kB pagetables:23440kB bounce:0kB free_pcp:1336kB local_pcp:672kB free_cma:0kB [ 44.966890] lowmem_reserve[]: 0 0 8 8 [ 44.966903] HighMem free:104kB min:128kB low:236kB high:244kB active_anon:2632kB inactive_anon:284kB active_file:1912kB inactive_file:1732kB unevictable:796kB writepending:0kB present:1056768kB managed:8192kB mlocked:796kB kernel_stack:0kB pagetables:180kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 44.966904] lowmem_reserve[]: 0 0 0 0 [ 44.966909] DMA: 148*4kB (UMH) 52*8kB (UMH) 30*16kB (UMH) 19*32kB (MH) 7*64kB (MH) 4*128kB (H) 5*256kB (H) 0*512kB 0*1024kB 1*2048kB (H) 1*4096kB (H) 0*8192kB 0*16384kB = 10480kB [ 44.966936] HighMem: 2*4kB (UM) 2*8kB (UM) 1*16kB (U) 0*32kB 1*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 104kB [ 44.966958] 74134 total pagecache pages [ 44.966961] 0 pages in swap cache [ 44.966963] Swap cache stats: add 0, delete 0, find 0/0 [ 44.966965] Free swap = 0kB [ 44.966966] Total swap = 0kB [ 44.966967] 496384 pages RAM [ 44.966969] 264192 pages HighMem/MovableOnly [ 44.966972] 271209 pages reserved [ 44.966975] 262144 pages cma reserved Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an empl
Page-allocation-failure
Hello , I am facing issue related to page allocation failure. If anyone is familiar with this issue, let me know what is the issue? How to solved/debug it. Failure logs -: - [ 45.073877] kswapd0: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null) [ 45.073897] CPU: 1 PID: 716 Comm: kswapd0 Tainted: P O4.14.65 #3 [ 45.073899] Hardware name: Android (Flattened Device Tree) [ 45.073901] Backtrace: [ 45.073915] [<8020dbec>] (dump_backtrace) from [<8020ded0>] (show_stack+0x18/0x1c) [ 45.073920] r6:600f0093 r5:8141bd5c r4: r3:3abdc664 [ 45.073928] [<8020deb8>] (show_stack) from [<80ba5e30>] (dump_stack+0x94/0xa8) [ 45.073936] [<80ba5d9c>] (dump_stack) from [<80350610>] (warn_alloc+0xe0/0x194) [ 45.073940] r6:80e090cc r5: r4:81216588 r3:3abdc664 [ 45.073946] [<80350534>] (warn_alloc) from [<803514e0>] (__alloc_pages_nodemask+0xd70/0x124c) [ 45.073949] r3: r2:80e090cc [ 45.073952] r6:0001 r5: r4:8121696c [ 45.073959] [<80350770>] (__alloc_pages_nodemask) from [<803a6c20>] (allocate_slab+0x364/0x3e4) [ 45.073964] r10:0080 r9: r8:01081220 r7: r6: r5:01080020 [ 45.073966] r4:bd00d180 [ 45.073971] [<803a68bc>] (allocate_slab) from [<803a8c98>] (___slab_alloc.constprop.6+0x420/0x4b8) [ 45.073977] r10: r9: r8:bd00d180 r7:01080020 r6:81216588 r5:be586360 [ 45.073978] r4: [ 45.073984] [<803a8878>] (___slab_alloc.constprop.6) from [<803a8d54>] (__slab_alloc.constprop.5+0x24/0x2c) [ 45.073989] r10:0004e299 r9:bd00d180 r8:01080020 r7:8147b954 r6:bd6e5a68 r5: [ 45.073991] r4:600f0093 [ 45.073996] [<803a8d30>] (__slab_alloc.constprop.5) from [<803a9058>] (kmem_cache_alloc+0x16c/0x2d0) [ 45.073999] r4:bd00d180 r3:be586360 --- Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: Print map for total physical and virtual memory
From: Matthew Wilcox Sent: 26 March 2019 17:06 To: Pankaj Suryawanshi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: [External] Re: Print map for total physical and virtual memory CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, Mar 26, 2019 at 08:34:20AM +, Pankaj Suryawanshi wrote: > Hello, > > 1. Is there any way to print whole physical and virtual memory map in > kernel/user space ? > > 2. Is there any way to print map of cma area reserved memory and movable > pages of cma area. > > 3. Is there any way to know who pinned the pages from cma reserved area ? You probably want tools/vm/page-types.c Can you please elaborate about tools/vm/page-types.c ? * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: vmscan: Reclaim unevictable pages
From: Michal Hocko Sent: 26 March 2019 14:31 To: Pankaj Suryawanshi Cc: Kirill Tkhai; Vlastimil Babka; aneesh.ku...@linux.ibm.com; linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; khand...@linux.vnet.ibm.com Subject: Re: [External] Re: vmscan: Reclaim unevictable pages [You were asked to use a reasonable quoting several times. This is really annoying because it turns the email thread into a complete mess] [Already fix the email client, but dont know the reason for quoting Maybe account issue.] On Tue 26-03-19 07:53:14, Pankaj Suryawanshi wrote: > Is there anyone who is familiar with this? Please Comment. Not really. You are observing an unexpected behavior of the page reclaim which hasn't changed for quite some time. So I find more probable that your non-vanilla kernel is doing something unexpected. It would help if you could track down how does the unevictable page get down to the reclaim path. I assume this is a CMA page or something like that but those shouldn't get to the reclaim path AFIR. As i said earlier, i am using vanilla kernel 4.14.65. -- Michal Hocko SUSE Labs * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: vmscan: Reclaim unevictable pages
From: Michal Hocko Sent: 26 March 2019 14:31 To: Pankaj Suryawanshi Cc: Kirill Tkhai; Vlastimil Babka; aneesh.ku...@linux.ibm.com; linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; khand...@linux.vnet.ibm.com Subject: Re: [External] Re: vmscan: Reclaim unevictable pages [You were asked to use a reasonable quoting several times. This is really annoying because it turns the email thread into a complete mess] I already fix the email client, dont know the reason for quoting. On Tue 26-03-19 07:53:14, Pankaj Suryawanshi wrote: > Is there anyone who is familiar with this? Please Comment. Not really. You are observing an unexpected behavior of the page reclaim which hasn't changed for quite some time. So I find more probable that your non-vanilla kernel is doing something unexpected. It would help if you could track down how does the unevictable page get down to the reclaim path. I assume this is a CMA page or something like that but those shouldn't get to the reclaim path AFIR. As i said earlier, the kernel i am using is vanilla kernel. -- Michal Hocko SUSE Labs * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Print map for total physical and virtual memory
Hello, 1. Is there any way to print whole physical and virtual memory map in kernel/user space ? 2. Is there any way to print map of cma area reserved memory and movable pages of cma area. 3. Is there any way to know who pinned the pages from cma reserved area ? Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: vmscan: Reclaim unevictable pages
From: Pankaj Suryawanshi
Sent: 20 March 2019 12:18
To: Kirill Tkhai; Vlastimil Babka; Michal Hocko; aneesh.ku...@linux.ibm.com
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
khand...@linux.vnet.ibm.com
Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
From: Kirill Tkhai
Sent: 18 March 2019 16:08
To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko;
aneesh.ku...@linux.ibm.com
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
khand...@linux.vnet.ibm.com
Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
On 18.03.2019 12:59, Pankaj Suryawanshi wrote:
>
> From: Kirill Tkhai
> Sent: 18 March 2019 15:17:56
> To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko;
> aneesh.ku...@linux.ibm.com
> Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
> khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com
> Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
Also, please, avoid irritating quoting like below ^^^. They just distract
attention.
> On 18.03.2019 12:43, Pankaj Suryawanshi wrote:
>> Hi Kirill Tkhai,
>>
>
> Please, do not top posting: https://kernelnewbies.org/mailinglistguidelines
>
> Okay.
>
> mailinglistguidelines - Linux Kernel Newbies
> kernelnewbies.org
> Set of FAQs for kernelnewbies mailing list. If you are new to this list
> please read this page before you go on your quest for squeezing all the
> knowledge from fellow members.
And this spew ^^^.
>> Please see mm/vmscan.c in which it first added to list and than throw the
>> error :
>> --
>> keep:
>> list_add(>lru, _pages);
>> VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page),
>> page);
>> ---
>>
>> Before throwing error, pages are added to list, this is under iteration of
>> shrink_page_list().
>
> I say about about the list, which is passed to shrink_page_list() as first
> argument.
> Did you mean candidate list which is passed to shrink_page_list().
>
> shrink_inactive_list()
> {
> isolate_lru_pages(_list); // <-- you can't obtain unevictable
> pages here.
> shrink_page_list(_list);
> }
>
> below is the overview of flow of calls for your information.
>
> cma_alloc() ->
> alloc_contig_range() ->
> start_isolate_page_range() ->
> __alloc_contig_migrate_range() ->
> isolate_migratepages_range() ->
> reclaim_clean_pages_from_list() ->
> shrink_page_list()
Hm, isolate_migratepages_range() can take unevictable pages,
but then with your patch we just skip them in shrink_page_list().
Without your patch we bump into bug on.
I don't see any other issue/effect if i apply this patch.
These both look incorrect for me. Let's wait someone who familiar
with this logic.
Is there anyone who is familiar with this? Please Comment.
>> From: Kirill Tkhai
>> Sent: 18 March 2019 15:03:15
>> To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko;
>> aneesh.ku...@linux.ibm.com
>> Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
>> khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com
>> Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
>>
>>
>> Hi, Pankaj,
>>
>> On 18.03.2019 12:09, Pankaj Suryawanshi wrote:
>>>
>>> Hello
>>>
>>> shrink_page_list() returns , number of pages reclaimed, when pages is
>>> unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) ||
>>> PageUnevicatble(page),page);
>>
>> the general idea is shrink_page_list() can't iterate PageUnevictable() pages.
>> PageUnevictable() pages are never being added to lists, which
>> shrink_page_list()
>> uses for iteration. Also, a page can't be marked as PageUnevictable(), when
>> it's attached to a shrinkable list.
>>
>> So, the problem should be somewhere outside shrink_page_list().
>>
>> I won't suggest you something about CMA, since I haven't dived in that code.
>>
>>> We can add the unevictable pages in reclaim list in shrink_page_list(),
>>> return total number of reclaim pages including unevictable pages, let the
>>> caller handle unevictable pages.
>>>
>>> I think the problem is shrink_page_list is awkard. If page is unevictable
>>> it goto activate_locked->keep_locked->keep lables, keep lable list_add the
>>> unevictable
Re: [External] Re: vmscan: Reclaim unevictable pages
From: Kirill Tkhai
Sent: 18 March 2019 16:08
To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko;
aneesh.ku...@linux.ibm.com
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
khand...@linux.vnet.ibm.com
Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
On 18.03.2019 12:59, Pankaj Suryawanshi wrote:
>
> From: Kirill Tkhai
> Sent: 18 March 2019 15:17:56
> To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko;
> aneesh.ku...@linux.ibm.com
> Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
> khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com
> Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
Also, please, avoid irritating quoting like below ^^^. They just distract
attention.
> On 18.03.2019 12:43, Pankaj Suryawanshi wrote:
>> Hi Kirill Tkhai,
>>
>
> Please, do not top posting: https://kernelnewbies.org/mailinglistguidelines
>
> Okay.
>
> mailinglistguidelines - Linux Kernel Newbies
> kernelnewbies.org
> Set of FAQs for kernelnewbies mailing list. If you are new to this list
> please read this page before you go on your quest for squeezing all the
> knowledge from fellow members.
And this spew ^^^.
>> Please see mm/vmscan.c in which it first added to list and than throw the
>> error :
>> --
>> keep:
>> list_add(>lru, _pages);
>> VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page),
>> page);
>> ---
>>
>> Before throwing error, pages are added to list, this is under iteration of
>> shrink_page_list().
>
> I say about about the list, which is passed to shrink_page_list() as first
> argument.
> Did you mean candidate list which is passed to shrink_page_list().
>
> shrink_inactive_list()
> {
> isolate_lru_pages(_list); // <-- you can't obtain unevictable
> pages here.
> shrink_page_list(_list);
> }
>
> below is the overview of flow of calls for your information.
>
> cma_alloc() ->
> alloc_contig_range() ->
> start_isolate_page_range() ->
> __alloc_contig_migrate_range() ->
> isolate_migratepages_range() ->
> reclaim_clean_pages_from_list() ->
> shrink_page_list()
Hm, isolate_migratepages_range() can take unevictable pages,
but then with your patch we just skip them in shrink_page_list().
Without your patch we bump into bug on.
I don't see any other issue/effect if i apply this patch.
These both look incorrect for me. Let's wait someone who familiar
with this logic.
>> From: Kirill Tkhai
>> Sent: 18 March 2019 15:03:15
>> To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko;
>> aneesh.ku...@linux.ibm.com
>> Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
>> khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com
>> Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
>>
>>
>> Hi, Pankaj,
>>
>> On 18.03.2019 12:09, Pankaj Suryawanshi wrote:
>>>
>>> Hello
>>>
>>> shrink_page_list() returns , number of pages reclaimed, when pages is
>>> unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) ||
>>> PageUnevicatble(page),page);
>>
>> the general idea is shrink_page_list() can't iterate PageUnevictable() pages.
>> PageUnevictable() pages are never being added to lists, which
>> shrink_page_list()
>> uses for iteration. Also, a page can't be marked as PageUnevictable(), when
>> it's attached to a shrinkable list.
>>
>> So, the problem should be somewhere outside shrink_page_list().
>>
>> I won't suggest you something about CMA, since I haven't dived in that code.
>>
>>> We can add the unevictable pages in reclaim list in shrink_page_list(),
>>> return total number of reclaim pages including unevictable pages, let the
>>> caller handle unevictable pages.
>>>
>>> I think the problem is shrink_page_list is awkard. If page is unevictable
>>> it goto activate_locked->keep_locked->keep lables, keep lable list_add the
>>> unevictable pages and throw the VM_BUG instead of passing it to caller
>>> while it relies on caller for non-reclaimed-non-unevictablepage's
>>> putback.
>>> I think we can make it consistent so that shrink_page_list could return
>>> non-reclaimed pages via page_list and caller can handle it. As an advance,
>>> it could try to migrate mlocked pages without retri
Re: [External] Re: mm/cma.c: High latency for cma allocation
From: Pankaj Suryawanshi Sent: 19 March 2019 15:59 To: Michal Hocko Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; minc...@kernel.org; Kirill Tkhai Subject: Re: [External] Re: mm/cma.c: High latency for cma allocation From: Michal Hocko Sent: 18 March 2019 19:59 To: Pankaj Suryawanshi Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; minc...@kernel.org; Kirill Tkhai Subject: Re: [External] Re: mm/cma.c: High latency for cma allocation On Mon 18-03-19 14:02:09, Pankaj Suryawanshi wrote: >> > I have the system(vanilla kernel) with 2GB of RAM, reserved 1GB for CMA. >> > No swap or zram. >> > Sorry, I don't have information where the time is spent. >> > time is calculated in between cma_alloc call. >> > I have just cma_alloc trace information/function graph. > >> Then please collect that data because it is really hard to judge >> anything from the numbers you have provided. > > Any pointers from which i can get this details ? I would start by enabling built in tracepoints for the migration or use a system wide perf monitoring with call graph data. Calling Sequence is as below. cma_alloc() --> alloc_contig_range() --> start_isolate_page_range() --> __alloc_contig_migrate_range() --> isolate_migratepages_range() --> reclaim_clean_pages_from_list() --> shrink_page_list() There is no built in tracepoints except cma_alloc. How to know where it taking time ? I have tried for latency count for 385MB: reclaim- reclaim_clean_pages_from_list() migrate- migrate_pages() migrateranges- isolate_migratepages_range() overall - __alloc_contig_migrate_range() Note: output is in us [ 1151.420923] LATENCY reclaim= 43 migrate=128 migrateranges=23 [ 1151.421209] LATENCY reclaim= 11 migrate=253 migrateranges=14 [ 1151.427856] LATENCY reclaim= 45 migrate=12 migrateranges=12 [ 1151.434485] LATENCY reclaim= 44 migrate=33 migrateranges=12 [ 1151.440975] LATENCY reclaim= 45 migrate=0 migrateranges=11 [ 1151.447513] LATENCY reclaim= 39 migrate=35 migrateranges=11 [ 1151.453919] LATENCY reclaim= 46 migrate=0 migrateranges=12 [ 1151.460474] LATENCY reclaim= 39 migrate=41 migrateranges=11 [ 1151.466947] LATENCY reclaim= 54 migrate=32 migrateranges=17 [ 1151.473464] LATENCY reclaim= 45 migrate=21 migrateranges=12 [ 1151.480016] LATENCY reclaim= 41 migrate=39 migrateranges=12 [ 1151.486551] LATENCY reclaim= 41 migrate=36 migrateranges=12 [ 1151.493199] LATENCY reclaim= 13 migrate=188 migrateranges=12 [ 1151.500034] LATENCY reclaim= 60 migrate=94 migrateranges=13 [ 1151.506686] LATENCY reclaim= 78 migrate=9 migrateranges=12 [ 1151.513313] LATENCY reclaim= 33 migrate=147 migrateranges=12 [ 1151.519839] LATENCY reclaim= 52 migrate=98 migrateranges=12 [ 1151.526556] LATENCY reclaim= 46 migrate=126 migrateranges=12 [ 1151.533254] LATENCY reclaim= 22 migrate=230 migrateranges=12 [ 1151.540145] LATENCY reclaim= 0 migrate=305 migrateranges=13 [ 1151.546997] LATENCY reclaim= 1 migrate=301 migrateranges=13 [ 1151.553686] LATENCY reclaim= 40 migrate=201 migrateranges=12 [ 1151.560395] LATENCY reclaim= 35 migrate=149 migrateranges=12 [ 1151.567076] LATENCY reclaim= 77 migrate=43 migrateranges=16 [ 1151.573836] LATENCY reclaim= 34 migrate=190 migrateranges=12 [ 1151.580510] LATENCY reclaim= 51 migrate=120 migrateranges=12 [ 1151.587240] LATENCY reclaim= 33 migrate=147 migrateranges=13 [ 1151.594036] LATENCY reclaim= 20 migrate=241 migrateranges=13 [ 1151.600749] LATENCY reclaim= 75 migrate=41 migrateranges=13 [ 1151.607402] LATENCY reclaim= 77 migrate=32 migrateranges=12 [ 1151.613956] LATENCY reclaim= 72 migrate=35 migrateranges=12 [ 1151.620642] LATENCY reclaim= 59 migrate=162 migrateranges=12 [ 1151.627181] LATENCY reclaim= 76 migrate=9 migrateranges=11 [ 1151.633795] LATENCY reclaim= 80 migrate=0 migrateranges=12 [ 1151.640278] LATENCY reclaim= 87 migrate=18 migrateranges=12 [ 1151.646758] LATENCY reclaim= 82 migrate=10 migrateranges=11 [ 1151.653307] LATENCY reclaim= 71 migrate=31 migrateranges=12 [ 1151.659911] LATENCY reclaim= 61 migrate=77 migrateranges=12 [ 1151.666514] LATENCY reclaim= 94 migrate=42 migrateranges=15 [ 1151.673089] LATENCY reclaim= 67 migrate=59 migrateranges=12 [ 1151.679655] LATENCY reclaim= 81 migrate=14 migrateranges=12 [ 1151.686253] LATENCY reclaim= 49 migrate=93 migrateranges=12 [ 1151.692815] LATENCY reclaim= 61 migrate=54 migrateranges=12 [ 1151.699438] LATENCY reclaim= 42 migrate=99 migrateranges=10 [ 1151.705881] OVERALL overall=285157 cma_alloc latency is = 297385 us Please let me know is there any workaround/solution to reduce large size buffer cma_alloc latency ? -- Michal Hocko SUSE Labs * eInfochips Business Disclaimer: This e-mail message and all attachments t
Re: [External] Re: mm/cma.c: High latency for cma allocation
From: Michal Hocko Sent: 18 March 2019 19:59 To: Pankaj Suryawanshi Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; minc...@kernel.org; Kirill Tkhai Subject: Re: [External] Re: mm/cma.c: High latency for cma allocation On Mon 18-03-19 14:02:09, Pankaj Suryawanshi wrote: >> > I have the system(vanilla kernel) with 2GB of RAM, reserved 1GB for CMA. >> > No swap or zram. >> > Sorry, I don't have information where the time is spent. >> > time is calculated in between cma_alloc call. >> > I have just cma_alloc trace information/function graph. > >> Then please collect that data because it is really hard to judge >> anything from the numbers you have provided. > > Any pointers from which i can get this details ? I would start by enabling built in tracepoints for the migration or use a system wide perf monitoring with call graph data. Calling Sequence is as below. cma_alloc() --> alloc_contig_range() --> start_isolate_page_range() --> __alloc_contig_migrate_range() --> isolate_migratepages_range() --> reclaim_clean_pages_from_list() --> shrink_page_list() There is no built in tracepoints except cma_alloc. How to know where it taking time ? -- Michal Hocko SUSE Labs * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: mm/cma.c: High latency for cma allocation
From: Michal Hocko Sent: 18 March 2019 19:12 To: Pankaj Suryawanshi Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; minc...@kernel.org; Kirill Tkhai Subject: Re: [External] Re: mm/cma.c: High latency for cma allocation [Please do not use html emails to the mailing list and try to fix your email client to not break quoating. Fixed for this email] okay. On Mon 18-03-19 13:28:50, Pankaj Suryawanshi wrote: > On Mon 18-03-19 12:58:28, Pankaj Suryawanshi wrote: > > > Hello, > > > > > > I am facing issue of high latency in CMA allocation of large size buffer. > > > > > > I am frequently allocating/deallocation CMA memory, latency of allocation > > > is very high. > > > > > > Below are the stat for allocation/deallocation latency issue. > > > > > > (390100 kB), latency 29997 us > > > (390100 kB), latency 22957 us > > > (390100 kB), latency 25735 us > > > (390100 kB), latency 12736 us > > > (390100 kB), latency 26009 us > > > (390100 kB), latency 18058 us > > > (390100 kB), latency 27997 us > > > (16 kB), latency 560 us > > > (256 kB), latency 280 us > > > (4 kB), latency 311 us > > > > > > I am using kernel 4.14.65 with android pie(9.0). > > > > > > Is there any workaround or solution for this(cma_alloc latency) issue ? > > > > Do you have any more detailed information on where the time is spent? > > E.g. migration tracepoints? > > > > Hello Michal, > > I have the system(vanilla kernel) with 2GB of RAM, reserved 1GB for CMA. No > swap or zram. > Sorry, I don't have information where the time is spent. > time is calculated in between cma_alloc call. > I have just cma_alloc trace information/function graph. Then please collect that data because it is really hard to judge anything from the numbers you have provided. Any pointers from which i can get this details ? -- Michal Hocko SUSE Labs * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: mm/cma.c: High latency for cma allocation
From: Michal Hocko Sent: 18 March 2019 18:37:57 To: Pankaj Suryawanshi Cc: linux...@kvack.org; linux-kernel@vger.kernel.org; minc...@kernel.org; Kirill Tkhai Subject: [External] Re: mm/cma.c: High latency for cma allocation CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon 18-03-19 12:58:28, Pankaj Suryawanshi wrote: > Hello, > > I am facing issue of high latency in CMA allocation of large size buffer. > > I am frequently allocating/deallocation CMA memory, latency of allocation is > very high. > > Below are the stat for allocation/deallocation latency issue. > > (390100 kB), latency 29997 us > (390100 kB), latency 22957 us > (390100 kB), latency 25735 us > (390100 kB), latency 12736 us > (390100 kB), latency 26009 us > (390100 kB), latency 18058 us > (390100 kB), latency 27997 us > (16 kB), latency 560 us > (256 kB), latency 280 us > (4 kB), latency 311 us > > I am using kernel 4.14.65 with android pie(9.0). > > Is there any workaround or solution for this(cma_alloc latency) issue ? Do you have any more detailed information on where the time is spent? E.g. migration tracepoints? Hello Michal, I have the system(vanilla kernel) with 2GB of RAM, reserved 1GB for CMA. No swap or zram. Sorry, I don't have information where the time is spent. time is calculated in between cma_alloc call. I have just cma_alloc trace information/function graph. -- Michal Hocko SUSE Labs * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
mm/cma.c: High latency for cma allocation
Hello, I am facing issue of high latency in CMA allocation of large size buffer. I am frequently allocating/deallocation CMA memory, latency of allocation is very high. Below are the stat for allocation/deallocation latency issue. (390100 kB), latency 29997 us (390100 kB), latency 22957 us (390100 kB), latency 25735 us (390100 kB), latency 12736 us (390100 kB), latency 26009 us (390100 kB), latency 18058 us (390100 kB), latency 27997 us (16 kB), latency 560 us (256 kB), latency 280 us (4 kB), latency 311 us I am using kernel 4.14.65 with android pie(9.0). Is there any workaround or solution for this(cma_alloc latency) issue ? Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [External] Re: vmscan: Reclaim unevictable pages
From: Kirill Tkhai
Sent: 18 March 2019 15:17:56
To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko;
aneesh.ku...@linux.ibm.com
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com
Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
On 18.03.2019 12:43, Pankaj Suryawanshi wrote:
> Hi Kirill Tkhai,
>
Please, do not top posting: https://kernelnewbies.org/mailinglistguidelines
Okay.
mailinglistguidelines - Linux Kernel Newbies
kernelnewbies.org
Set of FAQs for kernelnewbies mailing list. If you are new to this list please
read this page before you go on your quest for squeezing all the knowledge from
fellow members.
> Please see mm/vmscan.c in which it first added to list and than throw the
> error :
> --
> keep:
> list_add(>lru, _pages);
> VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page), page);
> ---
>
> Before throwing error, pages are added to list, this is under iteration of
> shrink_page_list().
I say about about the list, which is passed to shrink_page_list() as first
argument.
Did you mean candidate list which is passed to shrink_page_list().
shrink_inactive_list()
{
isolate_lru_pages(_list); // <-- you can't obtain unevictable
pages here.
shrink_page_list(_list);
}
below is the overview of flow of calls for your information.
cma_alloc() ->
alloc_contig_range() ->
start_isolate_page_range() ->
__alloc_contig_migrate_range() ->
isolate_migratepages_range() ->
reclaim_clean_pages_from_list() ->
shrink_page_list()
> From: Kirill Tkhai
> Sent: 18 March 2019 15:03:15
> To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko;
> aneesh.ku...@linux.ibm.com
> Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
> khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com
> Subject: Re: [External] Re: vmscan: Reclaim unevictable pages
>
>
> Hi, Pankaj,
>
> On 18.03.2019 12:09, Pankaj Suryawanshi wrote:
>>
>> Hello
>>
>> shrink_page_list() returns , number of pages reclaimed, when pages is
>> unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) ||
>> PageUnevicatble(page),page);
>
> the general idea is shrink_page_list() can't iterate PageUnevictable() pages.
> PageUnevictable() pages are never being added to lists, which
> shrink_page_list()
> uses for iteration. Also, a page can't be marked as PageUnevictable(), when
> it's attached to a shrinkable list.
>
> So, the problem should be somewhere outside shrink_page_list().
>
> I won't suggest you something about CMA, since I haven't dived in that code.
>
>> We can add the unevictable pages in reclaim list in shrink_page_list(),
>> return total number of reclaim pages including unevictable pages, let the
>> caller handle unevictable pages.
>>
>> I think the problem is shrink_page_list is awkard. If page is unevictable it
>> goto activate_locked->keep_locked->keep lables, keep lable list_add the
>> unevictable pages and throw the VM_BUG instead of passing it to caller while
>> it relies on caller for non-reclaimed-non-unevictable page's putback.
>> I think we can make it consistent so that shrink_page_list could return
>> non-reclaimed pages via page_list and caller can handle it. As an advance,
>> it could try to migrate mlocked pages without retrial.
>>
>>
>> Below is the issue of CMA_ALLOC of large size buffer : (Kernel version -
>> 4.14.65 (On Android pie [ARM])).
>>
>> [ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) ||
>> PageUnevictable(page))
>> [ 24.726949] page->mem_cgroup:bd008c00
>> [ 24.730693] [ cut here ]
>> [ 24.735304] kernel BUG at mm/vmscan.c:1350!
>> [ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
>>
>>
>> Below is the patch which solved this issue :
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index be56e2e..12ac353 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head
>> *page_list,
>> sc->nr_scanned++;
>>
>> if (unlikely(!page_evictable(page)))
>> - goto activate_locked;
>> + goto cull_mlocked;
>>
>> if (!sc->may_unmap && page_mapped(page))
>> goto keep_locked;
>&g
Re: [External] Re: vmscan: Reclaim unevictable pages
Hi Kirill Tkhai, Please see mm/vmscan.c in which it first added to list and than throw the error : -- keep: list_add(>lru, _pages); VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page), page); --- Before throwing error, pages are added to list, this is under iteration of shrink_page_list(). From: Kirill Tkhai Sent: 18 March 2019 15:03:15 To: Pankaj Suryawanshi; Vlastimil Babka; Michal Hocko; aneesh.ku...@linux.ibm.com Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com Subject: Re: [External] Re: vmscan: Reclaim unevictable pages Hi, Pankaj, On 18.03.2019 12:09, Pankaj Suryawanshi wrote: > > Hello > > shrink_page_list() returns , number of pages reclaimed, when pages is > unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) || > PageUnevicatble(page),page); the general idea is shrink_page_list() can't iterate PageUnevictable() pages. PageUnevictable() pages are never being added to lists, which shrink_page_list() uses for iteration. Also, a page can't be marked as PageUnevictable(), when it's attached to a shrinkable list. So, the problem should be somewhere outside shrink_page_list(). I won't suggest you something about CMA, since I haven't dived in that code. > We can add the unevictable pages in reclaim list in shrink_page_list(), > return total number of reclaim pages including unevictable pages, let the > caller handle unevictable pages. > > I think the problem is shrink_page_list is awkard. If page is unevictable it > goto activate_locked->keep_locked->keep lables, keep lable list_add the > unevictable pages and throw the VM_BUG instead of passing it to caller while > it relies on caller for non-reclaimed-non-unevictable page's putback. > I think we can make it consistent so that shrink_page_list could return > non-reclaimed pages via page_list and caller can handle it. As an advance, it > could try to migrate mlocked pages without retrial. > > > Below is the issue of CMA_ALLOC of large size buffer : (Kernel version - > 4.14.65 (On Android pie [ARM])). > > [ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || > PageUnevictable(page)) > [ 24.726949] page->mem_cgroup:bd008c00 > [ 24.730693] [ cut here ] > [ 24.735304] kernel BUG at mm/vmscan.c:1350! > [ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM > > > Below is the patch which solved this issue : > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index be56e2e..12ac353 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head > *page_list, > sc->nr_scanned++; > > if (unlikely(!page_evictable(page))) > - goto activate_locked; > + goto cull_mlocked; > > if (!sc->may_unmap && page_mapped(page)) > goto keep_locked; > @@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head > *page_list, > } else > list_add(>lru, _pages); > continue; > - > +cull_mlocked: > + if (PageSwapCache(page)) > + try_to_free_swap(page); > + unlock_page(page); > + list_add(>lru, _pages); > + continue; > activate_locked: > /* Not a candidate for swapping, so reclaim swap space. */ > if (PageSwapCache(page) && (mem_cgroup_swap_full(page) || > > > > > It fixes the below issue. > > 1. Large size buffer allocation using cma_alloc successful with unevictable > pages. > > cma_alloc of current kernel will fail due to unevictable page > > Please let me know if anything i am missing. > > Regards, > Pankaj > > From: Vlastimil Babka > Sent: 18 March 2019 14:12:50 > To: Pankaj Suryawanshi; Kirill Tkhai; Michal Hocko; aneesh.ku...@linux.ibm.com > Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; > khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com > Subject: Re: [External] Re: vmscan: Reclaim unevictable pages > > > On 3/15/19 11:11 AM, Pankaj Suryawanshi wrote: >> >> [ cc Aneesh kumar, Anshuman, Hillf, Vlastimil] > > Can you send a proper patch with changelog explaining the change? I > don't know the context of this thread. > >> From: Pankaj Suryawanshi >> S
Re: [External] Re: vmscan: Reclaim unevictable pages
Hello shrink_page_list() returns , number of pages reclaimed, when pages is unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) || PageUnevicatble(page),page); We can add the unevictable pages in reclaim list in shrink_page_list(), return total number of reclaim pages including unevictable pages, let the caller handle unevictable pages. I think the problem is shrink_page_list is awkard. If page is unevictable it goto activate_locked->keep_locked->keep lables, keep lable list_add the unevictable pages and throw the VM_BUG instead of passing it to caller while it relies on caller for non-reclaimed-non-unevictable page's putback. I think we can make it consistent so that shrink_page_list could return non-reclaimed pages via page_list and caller can handle it. As an advance, it could try to migrate mlocked pages without retrial. Below is the issue of CMA_ALLOC of large size buffer : (Kernel version - 4.14.65 (On Android pie [ARM])). [ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page)) [ 24.726949] page->mem_cgroup:bd008c00 [ 24.730693] [ cut here ] [ 24.735304] kernel BUG at mm/vmscan.c:1350! [ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Below is the patch which solved this issue : diff --git a/mm/vmscan.c b/mm/vmscan.c index be56e2e..12ac353 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head *page_list, sc->nr_scanned++; if (unlikely(!page_evictable(page))) - goto activate_locked; + goto cull_mlocked; if (!sc->may_unmap && page_mapped(page)) goto keep_locked; @@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head *page_list, } else list_add(>lru, _pages); continue; - +cull_mlocked: + if (PageSwapCache(page)) + try_to_free_swap(page); + unlock_page(page); + list_add(>lru, _pages); + continue; activate_locked: /* Not a candidate for swapping, so reclaim swap space. */ if (PageSwapCache(page) && (mem_cgroup_swap_full(page) || It fixes the below issue. 1. Large size buffer allocation using cma_alloc successful with unevictable pages. cma_alloc of current kernel will fail due to unevictable page Please let me know if anything i am missing. Regards, Pankaj From: Vlastimil Babka Sent: 18 March 2019 14:12:50 To: Pankaj Suryawanshi; Kirill Tkhai; Michal Hocko; aneesh.ku...@linux.ibm.com Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com Subject: Re: [External] Re: vmscan: Reclaim unevictable pages On 3/15/19 11:11 AM, Pankaj Suryawanshi wrote: > > [ cc Aneesh kumar, Anshuman, Hillf, Vlastimil] Can you send a proper patch with changelog explaining the change? I don't know the context of this thread. > From: Pankaj Suryawanshi > Sent: 15 March 2019 11:35:05 > To: Kirill Tkhai; Michal Hocko > Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org > Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages > > > > [ cc linux-mm ] > > > From: Pankaj Suryawanshi > Sent: 14 March 2019 19:14:40 > To: Kirill Tkhai; Michal Hocko > Cc: linux-kernel@vger.kernel.org; minc...@kernel.org > Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages > > > > Hello , > > Please ignore the curly braces, they are just for debugging. > > Below is the updated patch. > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index be56e2e..12ac353 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head > *page_list, > sc->nr_scanned++; > > if (unlikely(!page_evictable(page))) > - goto activate_locked; > + goto cull_mlocked; > > if (!sc->may_unmap && page_mapped(page)) > goto keep_locked; > @@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head > *page_list, > } else > list_add(>lru, _pages); > continue; > - > +cull_mlocked: > + if (PageSwapCache(page)) > + try_to_free_swap(page); > + unlock_page(page); > + list_add(>lru, _pages); > + continue; > activate_locked: > /* Not a candidate for swapping, so reclaim swap space. */ >
Re: vmscan: Reclaim unevictable pages
Hello shrink_page_list() returns , number of pages reclaimed, when pages is unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) || PageUnevicatble(page),page); We can add the unevictable pages in reclaim list in shrink_page_list(), return total number of reclaim pages including unevictable pages, let the caller handle unevictable pages. I think the problem is shrink_page_list is awkard. If page is unevictable it goto activate_locked->keep_locked->keep lables, keep lable list_add the unevictable pages and throw the VM_BUG instead of passing it to caller while it relies on caller for non-reclaimed-non-unevictable page's putback. I think we can make it consistent so that shrink_page_list could return non-reclaimed pages via page_list and caller can handle it. As an advance, it could try to migrate mlocked pages without retrial. Below is the issue of CMA_ALLOC of large size buffer : (Kernel version - 4.14.65 (On Android pie [ARM])). [ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page)) [ 24.726949] page->mem_cgroup:bd008c00 [ 24.730693] [ cut here ] [ 24.735304] kernel BUG at mm/vmscan.c:1350! [ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Below is the patch which solved this issue : diff --git a/mm/vmscan.c b/mm/vmscan.c index be56e2e..12ac353 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head *page_list, sc->nr_scanned++; if (unlikely(!page_evictable(page))) - goto activate_locked; + goto cull_mlocked; if (!sc->may_unmap && page_mapped(page)) goto keep_locked; @@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head *page_list, } else list_add(>lru, _pages); continue; - +cull_mlocked: +if (PageSwapCache(page)) +try_to_free_swap(page); +unlock_page(page); +list_add(>lru, _pages); +continue; activate_locked: /* Not a candidate for swapping, so reclaim swap space. */ if (PageSwapCache(page) && (mem_cgroup_swap_full(page) || It fixes the below issue. 1. Large size buffer allocation using cma_alloc successful with unevictable pages. cma_alloc of current kernel will fail due to unevictable page Please let me know if anything i am missing. Regards, Pankaj From: Pankaj Suryawanshi Sent: 18 March 2019 13:15:22 To: Kirill Tkhai; Michal Hocko; aneesh.ku...@linux.ibm.com Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; khand...@linux.vnet.ibm.com; vba...@suse.cz Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages It fixes the below issue. 1. Large size buffer allocation using cma_alloc successful with unevictable pages. cma_alloc of current kernel will fail due to unevictable pages. Solved the below issue of cma_alloc - [ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page)) [ 24.726949] page->mem_cgroup:bd008c00 [ 24.730693] [ cut here ] [ 24.735304] kernel BUG at mm/vmscan.c:1350! [ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM --------- From: Pankaj Suryawanshi Sent: 15 March 2019 15:41:57 To: Kirill Tkhai; Michal Hocko; aneesh.ku...@linux.ibm.com Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org; khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com; vba...@suse.cz Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages [ cc Aneesh kumar, Anshuman, Hillf, Vlastimil] From: Pankaj Suryawanshi Sent: 15 March 2019 11:35:05 To: Kirill Tkhai; Michal Hocko Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages [ cc linux-mm ] From: Pankaj Suryawanshi Sent: 14 March 2019 19:14:40 To: Kirill Tkhai; Michal Hocko Cc: linux-kernel@vger.kernel.org; minc...@kernel.org Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages Hello , Please ignore the curly braces, they are just for debugging. Below is the updated patch. diff --git a/mm/vmscan.c b/mm/vmscan.c index be56e2e..12ac353 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head *page_list, sc->nr_scanned++; if (unlikely(!page_evictable(page))) - goto activate_locke
Re: Re: [External] Re: vmscan: Reclaim unevictable pages
It fixes the below issue.
1. Large size buffer allocation using cma_alloc successful with unevictable
pages.
cma_alloc of current kernel will fail due to unevictable pages.
Solved the below issue of cma_alloc
-
[ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) ||
PageUnevictable(page))
[ 24.726949] page->mem_cgroup:bd008c00
[ 24.730693] [ cut here ]
[ 24.735304] kernel BUG at mm/vmscan.c:1350!
[ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
-
From: Pankaj Suryawanshi
Sent: 15 March 2019 15:41:57
To: Kirill Tkhai; Michal Hocko; aneesh.ku...@linux.ibm.com
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org;
khand...@linux.vnet.ibm.com; hillf...@alibaba-inc.com; vba...@suse.cz
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
[ cc Aneesh kumar, Anshuman, Hillf, Vlastimil]
From: Pankaj Suryawanshi
Sent: 15 March 2019 11:35:05
To: Kirill Tkhai; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
[ cc linux-mm ]
From: Pankaj Suryawanshi
Sent: 14 March 2019 19:14:40
To: Kirill Tkhai; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
Hello ,
Please ignore the curly braces, they are just for debugging.
Below is the updated patch.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index be56e2e..12ac353 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
sc->nr_scanned++;
if (unlikely(!page_evictable(page)))
- goto activate_locked;
+ goto cull_mlocked;
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
@@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
} else
list_add(>lru, _pages);
continue;
-
+cull_mlocked:
+if (PageSwapCache(page))
+try_to_free_swap(page);
+unlock_page(page);
+list_add(>lru, _pages);
+continue;
activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
if (PageSwapCache(page) && (mem_cgroup_swap_full(page) ||
Regards,
Pankaj
From: Kirill Tkhai
Sent: 14 March 2019 14:55:34
To: Pankaj Suryawanshi; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
On 14.03.2019 11:52, Pankaj Suryawanshi wrote:
>
> I am using kernel version 4.14.65 (on Android pie [ARM]).
>
> No additional patches applied on top of vanilla.(Core MM).
>
> If I change in the vmscan.c as below patch, it will work.
Sorry, but 4.14.65 does not have braces around trylock_page(),
like in your patch below.
See
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/vmscan.c?h=v4.14.65
[...]
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index be56e2e..2e51edc 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -990,15 +990,17 @@ static unsigned long shrink_page_list(struct list_head
>> *page_list,
>> page = lru_to_page(page_list);
>> list_del(>lru);
>>
>> if (!trylock_page(page)) {
>> goto keep;
>> }
*
eInfochips Business Disclaimer: This e-mail message and all attachments
transmitted with it are intended solely for the use of the addressee and may
contain legally privileged and confidential information. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution, copying, or other use of this message or its
attachments is strictly prohibited. If you have received this message in error,
please notify the sender immediately by replying to this message and please
delete it from your computer. Any views expressed in this message are those of
the individual sender unless otherwise stated. Company has taken enough
precautions to prevent the spread of viruses. However the company accepts no
liability for any damage caused by any virus transmitted by this email.
*
Re: Re: [External] Re: vmscan: Reclaim unevictable pages
[ cc Aneesh kumar, Anshuman, Hillf, Vlastimil]
From: Pankaj Suryawanshi
Sent: 15 March 2019 11:35:05
To: Kirill Tkhai; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org; linux...@kvack.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
[ cc linux-mm ]
From: Pankaj Suryawanshi
Sent: 14 March 2019 19:14:40
To: Kirill Tkhai; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
Hello ,
Please ignore the curly braces, they are just for debugging.
Below is the updated patch.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index be56e2e..12ac353 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
sc->nr_scanned++;
if (unlikely(!page_evictable(page)))
- goto activate_locked;
+ goto cull_mlocked;
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
@@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
} else
list_add(>lru, _pages);
continue;
-
+cull_mlocked:
+if (PageSwapCache(page))
+try_to_free_swap(page);
+unlock_page(page);
+list_add(>lru, _pages);
+continue;
activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
if (PageSwapCache(page) && (mem_cgroup_swap_full(page) ||
Regards,
Pankaj
From: Kirill Tkhai
Sent: 14 March 2019 14:55:34
To: Pankaj Suryawanshi; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
On 14.03.2019 11:52, Pankaj Suryawanshi wrote:
>
> I am using kernel version 4.14.65 (on Android pie [ARM]).
>
> No additional patches applied on top of vanilla.(Core MM).
>
> If I change in the vmscan.c as below patch, it will work.
Sorry, but 4.14.65 does not have braces around trylock_page(),
like in your patch below.
See
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/vmscan.c?h=v4.14.65
[...]
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index be56e2e..2e51edc 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -990,15 +990,17 @@ static unsigned long shrink_page_list(struct list_head
>> *page_list,
>> page = lru_to_page(page_list);
>> list_del(>lru);
>>
>> if (!trylock_page(page)) {
>> goto keep;
>> }
*
eInfochips Business Disclaimer: This e-mail message and all attachments
transmitted with it are intended solely for the use of the addressee and may
contain legally privileged and confidential information. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution, copying, or other use of this message or its
attachments is strictly prohibited. If you have received this message in error,
please notify the sender immediately by replying to this message and please
delete it from your computer. Any views expressed in this message are those of
the individual sender unless otherwise stated. Company has taken enough
precautions to prevent the spread of viruses. However the company accepts no
liability for any damage caused by any virus transmitted by this email.
*
High Latency of CMA allocation
Hello, I am facing issue of high latency in CMA allocation of large size buffer . I am frequently allocating/deallocation CMA memory, but latency of allocation is very high. Below are the stat for allocation/deallocation latency issue. (389120 kB), latency 29997 us (389120 kB), latency 22957 us (389120 kB), latency 25735 us (389120 kB), latency 12736 us (389120 kB), latency 26009 us (389120 kB), latency 18058 us (389120 kB), latency 27997 us (16 kB), latency 560 us (256 kB), latency 280 us (4 kB), latency 311 us Is there any workaround or solution for this(cma_alloc latency) issue ? Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: Re: [External] Re: vmscan: Reclaim unevictable pages
[ cc linux-mm ]
From: Pankaj Suryawanshi
Sent: 14 March 2019 19:14:40
To: Kirill Tkhai; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
Hello ,
Please ignore the curly braces, they are just for debugging.
Below is the updated patch.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index be56e2e..12ac353 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
sc->nr_scanned++;
if (unlikely(!page_evictable(page)))
- goto activate_locked;
+ goto cull_mlocked;
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
@@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
} else
list_add(>lru, _pages);
continue;
-
+cull_mlocked:
+if (PageSwapCache(page))
+try_to_free_swap(page);
+unlock_page(page);
+list_add(>lru, _pages);
+continue;
activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
if (PageSwapCache(page) && (mem_cgroup_swap_full(page) ||
Regards,
Pankaj
From: Kirill Tkhai
Sent: 14 March 2019 14:55:34
To: Pankaj Suryawanshi; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
On 14.03.2019 11:52, Pankaj Suryawanshi wrote:
>
> I am using kernel version 4.14.65 (on Android pie [ARM]).
>
> No additional patches applied on top of vanilla.(Core MM).
>
> If I change in the vmscan.c as below patch, it will work.
Sorry, but 4.14.65 does not have braces around trylock_page(),
like in your patch below.
See
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/vmscan.c?h=v4.14.65
[...]
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index be56e2e..2e51edc 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -990,15 +990,17 @@ static unsigned long shrink_page_list(struct list_head
>> *page_list,
>> page = lru_to_page(page_list);
>> list_del(>lru);
>>
>> if (!trylock_page(page)) {
>> goto keep;
>> }
*
eInfochips Business Disclaimer: This e-mail message and all attachments
transmitted with it are intended solely for the use of the addressee and may
contain legally privileged and confidential information. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution, copying, or other use of this message or its
attachments is strictly prohibited. If you have received this message in error,
please notify the sender immediately by replying to this message and please
delete it from your computer. Any views expressed in this message are those of
the individual sender unless otherwise stated. Company has taken enough
precautions to prevent the spread of viruses. However the company accepts no
liability for any damage caused by any virus transmitted by this email.
*
Re: Re: [External] Re: vmscan: Reclaim unevictable pages
Hello ,
Please ignore the curly braces, they are just for debugging.
Below is the updated patch.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index be56e2e..12ac353 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
sc->nr_scanned++;
if (unlikely(!page_evictable(page)))
- goto activate_locked;
+ goto cull_mlocked;
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
@@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
} else
list_add(>lru, _pages);
continue;
-
+cull_mlocked:
+if (PageSwapCache(page))
+try_to_free_swap(page);
+unlock_page(page);
+list_add(>lru, _pages);
+continue;
activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
if (PageSwapCache(page) && (mem_cgroup_swap_full(page) ||
Regards,
Pankaj
From: Kirill Tkhai
Sent: 14 March 2019 14:55:34
To: Pankaj Suryawanshi; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
On 14.03.2019 11:52, Pankaj Suryawanshi wrote:
>
> I am using kernel version 4.14.65 (on Android pie [ARM]).
>
> No additional patches applied on top of vanilla.(Core MM).
>
> If I change in the vmscan.c as below patch, it will work.
Sorry, but 4.14.65 does not have braces around trylock_page(),
like in your patch below.
See
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/vmscan.c?h=v4.14.65
[...]
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index be56e2e..2e51edc 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -990,15 +990,17 @@ static unsigned long shrink_page_list(struct list_head
>> *page_list,
>> page = lru_to_page(page_list);
>> list_del(>lru);
>>
>> if (!trylock_page(page)) {
>> goto keep;
>> }
*
eInfochips Business Disclaimer: This e-mail message and all attachments
transmitted with it are intended solely for the use of the addressee and may
contain legally privileged and confidential information. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution, copying, or other use of this message or its
attachments is strictly prohibited. If you have received this message in error,
please notify the sender immediately by replying to this message and please
delete it from your computer. Any views expressed in this message are those of
the individual sender unless otherwise stated. Company has taken enough
precautions to prevent the spread of viruses. However the company accepts no
liability for any damage caused by any virus transmitted by this email.
*
Re: Re: [External] Re: vmscan: Reclaim unevictable pages
Hello ,
The curly braces are just for debugging purpose so please ignore it.
Below is the updated patch :
if (!trylock_page(page))
goto keep;
VM_BUG_ON_PAGE(PageActive(page), page);
sc->nr_scanned++;
if (unlikely(!page_evictable(page)))
- goto activate_locked;
+ goto cull_mlocked;
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
@@ -1331,6 +1333,12 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
} else
list_add(>lru, _pages);
continue;
+cull_mlocked:
+if (PageSwapCache(page))
+try_to_free_swap(page);
+unlock_page(page);
+list_add(>lru, _pages);
+continue;
activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
From: Kirill Tkhai
Sent: 14 March 2019 14:55:34
To: Pankaj Suryawanshi; Michal Hocko
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: Re: Re: [External] Re: vmscan: Reclaim unevictable pages
On 14.03.2019 11:52, Pankaj Suryawanshi wrote:
>
> I am using kernel version 4.14.65 (on Android pie [ARM]).
>
> No additional patches applied on top of vanilla.(Core MM).
>
> If I change in the vmscan.c as below patch, it will work.
Sorry, but 4.14.65 does not have braces around trylock_page(),
like in your patch below.
See
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/mm/vmscan.c?h=v4.14.65
[...]
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index be56e2e..2e51edc 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -990,15 +990,17 @@ static unsigned long shrink_page_list(struct list_head
>> *page_list,
>> page = lru_to_page(page_list);
>> list_del(>lru);
>>
>> if (!trylock_page(page)) {
>> goto keep;
>> }
*
eInfochips Business Disclaimer: This e-mail message and all attachments
transmitted with it are intended solely for the use of the addressee and may
contain legally privileged and confidential information. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution, copying, or other use of this message or its
attachments is strictly prohibited. If you have received this message in error,
please notify the sender immediately by replying to this message and please
delete it from your computer. Any views expressed in this message are those of
the individual sender unless otherwise stated. Company has taken enough
precautions to prevent the spread of viruses. However the company accepts no
liability for any damage caused by any virus transmitted by this email.
*
Re: [External] Re: vmscan: Reclaim unevictable pages
I am using kernel version 4.14.65 (on Android pie [ARM]).
No additional patches applied on top of vanilla.(Core MM).
If I change in the vmscan.c as below patch, it will work.
Regards,
Pankaj
From: Michal Hocko
Sent: 14 March 2019 14:11:20
To: Pankaj Suryawanshi
Cc: linux-kernel@vger.kernel.org; minc...@kernel.org
Subject: [External] Re: vmscan: Reclaim unevictable pages
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On Thu 14-03-19 08:23:10, Pankaj Suryawanshi wrote:
>
> Below is the Error Msg :
>
> [ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) ||
> PageUnevictable(page))
> [ 24.726949] page->mem_cgroup:bd008c00
> [ 24.730693] [ cut here ]
> [ 24.735304] kernel BUG at mm/vmscan.c:1350!
> [ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Just curious. Which kernel version is that? Are there any addional
patches applied on top of vanilla?
> Solved the issue by below patch.
>
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index be56e2e..2e51edc 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -990,15 +990,17 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> page = lru_to_page(page_list);
> list_del(>lru);
>
> if (!trylock_page(page)) {
> goto keep;
> }
>
> VM_BUG_ON_PAGE(PageActive(page), page);
>
> sc->nr_scanned++;
>
> if (unlikely(!page_evictable(page)))
> - goto activate_locked;
> + goto cull_mlocked;
>
> if (!sc->may_unmap && page_mapped(page))
> goto keep_locked;
> @@ -1331,6 +1333,12 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> } else
> list_add(>lru, _pages);
> continue;
> +cull_mlocked:
> + if (PageSwapCache(page))
> + try_to_free_swap(page);
> + unlock_page(page);
> + list_add(>lru, _pages);
> + continue;
>
> activate_locked:
> /* Not a candidate for swapping, so reclaim swap space. */
>
>
>
>
> From: Pankaj Suryawanshi
> Sent: 14 March 2019 13:23:53
> To: linux-kernel@vger.kernel.org
> Cc: minc...@kernel.org
> Subject: vmscan: Reclaim unevictable pages
>
>
>
> Hello ,
>
> shrink_page_list() returns , number of pages reclaimed, when pages is
> unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) ||
> PageUnevicatble(page),page);
>
> We can add the unevictable pages in reclaim list in shrink_page_list(),
> return total number of reclaim pages including unevictable pages, let the
> caller handle unevictable pages.
>
> Regards,
> Pankaj
>
> *
> eInfochips Business Disclaimer: This e-mail message and all attachments
> transmitted with it are intended solely for the use of the addressee and may
> contain legally privileged and confidential information. If the reader of
> this message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient, you are
> hereby notified that any dissemination, distribution, copying, or other use
> of this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any views
> expressed in this message are those of the individual sender unless otherwise
> stated. Company has taken enough precautions to prevent the spread of
> viruses. However the company accepts no liability for any damage caused by
> any virus transmitted by this email.
> *
--
Michal Hocko
SUSE Labs
Re: vmscan: Reclaim unevictable pages
Below is the Error Msg :
[ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) ||
PageUnevictable(page))
[ 24.726949] page->mem_cgroup:bd008c00
[ 24.730693] [ cut here ]
[ 24.735304] kernel BUG at mm/vmscan.c:1350!
[ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Solved the issue by below patch.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index be56e2e..2e51edc 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -990,15 +990,17 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
page = lru_to_page(page_list);
list_del(>lru);
if (!trylock_page(page)) {
goto keep;
}
VM_BUG_ON_PAGE(PageActive(page), page);
sc->nr_scanned++;
if (unlikely(!page_evictable(page)))
- goto activate_locked;
+ goto cull_mlocked;
if (!sc->may_unmap && page_mapped(page))
goto keep_locked;
@@ -1331,6 +1333,12 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
} else
list_add(>lru, _pages);
continue;
+cull_mlocked:
+if (PageSwapCache(page))
+try_to_free_swap(page);
+unlock_page(page);
+list_add(>lru, _pages);
+continue;
activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
From: Pankaj Suryawanshi
Sent: 14 March 2019 13:23:53
To: linux-kernel@vger.kernel.org
Cc: minc...@kernel.org
Subject: vmscan: Reclaim unevictable pages
Hello ,
shrink_page_list() returns , number of pages reclaimed, when pages is
unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) ||
PageUnevicatble(page),page);
We can add the unevictable pages in reclaim list in shrink_page_list(), return
total number of reclaim pages including unevictable pages, let the caller
handle unevictable pages.
Regards,
Pankaj
*
eInfochips Business Disclaimer: This e-mail message and all attachments
transmitted with it are intended solely for the use of the addressee and may
contain legally privileged and confidential information. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution, copying, or other use of this message or its
attachments is strictly prohibited. If you have received this message in error,
please notify the sender immediately by replying to this message and please
delete it from your computer. Any views expressed in this message are those of
the individual sender unless otherwise stated. Company has taken enough
precautions to prevent the spread of viruses. However the company accepts no
liability for any damage caused by any virus transmitted by this email.
*
vmscan: Reclaim unevictable pages
Hello , shrink_page_list() returns , number of pages reclaimed, when pages is unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) || PageUnevicatble(page),page); We can add the unevictable pages in reclaim list in shrink_page_list(), return total number of reclaim pages including unevictable pages, let the caller handle unevictable pages. Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
