search for: __alloc_pages_direct_compact

...t_pages+0x2f1/0x648 > kernel: [<ffffffff8122ce88>] ? try_to_compact_pages+0x2f1/0x648 > kernel: [<ffffffff8122cb97>] ? compaction_zonelist_suitable+0x3a6/0x3a6 > kernel: [<ffffffff811ef1ea>] ? get_page_from_freelist+0x2c0/0x133c > kernel: [<ffffffff811f0350>] __alloc_pages_direct_compact+0xea/0x30d > kernel: [<ffffffff811f0266>] ? get_page_from_freelist+0x133c/0x133c > kernel: [<ffffffff811ee3b2>] ? drain_all_pages+0x1d6/0x205 > kernel: [<ffffffff811f21a8>] __alloc_pages_nodemask+0x143d/0x16b6 > kernel: [<ffffffff8111f405>] ? debug_show_all_l...

...t_pages+0x2f1/0x648 > kernel: [<ffffffff8122ce88>] ? try_to_compact_pages+0x2f1/0x648 > kernel: [<ffffffff8122cb97>] ? compaction_zonelist_suitable+0x3a6/0x3a6 > kernel: [<ffffffff811ef1ea>] ? get_page_from_freelist+0x2c0/0x133c > kernel: [<ffffffff811f0350>] __alloc_pages_direct_compact+0xea/0x30d > kernel: [<ffffffff811f0266>] ? get_page_from_freelist+0x133c/0x133c > kernel: [<ffffffff811ee3b2>] ? drain_all_pages+0x1d6/0x205 > kernel: [<ffffffff811f21a8>] __alloc_pages_nodemask+0x143d/0x16b6 > kernel: [<ffffffff8111f405>] ? debug_show_all_l...

...e of our systems could run in steady state will little free memory and 100% fragmentation. Now I see 10-30x more memory free (read: not utilized). Order > 0 allocations were happening rarely before, now it happens consistently from this function. My suggestion above would avoid mm going through __alloc_pages_direct_compact() and triggering the bad events above. It will take me several days to try this experiment. -Debabrata On Tue, Dec 24, 2013 at 5:46 PM, David Miller <davem at davemloft.net> wrote: > > There is still feedback and/or minor adjustments being asked for wrt. > this series. These chan...

...e of our systems could run in steady state will little free memory and 100% fragmentation. Now I see 10-30x more memory free (read: not utilized). Order > 0 allocations were happening rarely before, now it happens consistently from this function. My suggestion above would avoid mm going through __alloc_pages_direct_compact() and triggering the bad events above. It will take me several days to try this experiment. -Debabrata On Tue, Dec 24, 2013 at 5:46 PM, David Miller <davem at davemloft.net> wrote: > > There is still feedback and/or minor adjustments being asked for wrt. > this series. These chan...

...0x2f1/0x648 [ 315.147550] [<ffffffff8122bcff>] ? try_to_compact_pages+0x2f1/0x648 [ 315.147568] [<ffffffff8122ba0e>] ? compaction_zonelist_suitable+0x3a6/0x3a6 [ 315.147589] [<ffffffff811ee129>] ? get_page_from_freelist+0x2c0/0x129a [ 315.147608] [<ffffffff811ef1ed>] __alloc_pages_direct_compact+0xea/0x30d [ 315.147626] [<ffffffff811ef103>] ? get_page_from_freelist+0x129a/0x129a [ 315.147645] [<ffffffff811f0422>] __alloc_pages_nodemask+0x840/0x16b6 [ 315.147663] [<ffffffff810dba27>] ? try_to_wake_up+0x696/0x6c8 [ 315.149147] [<ffffffff811efbe2>] ? warn_alloc...

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > > > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > > > [

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > > > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > > > [

...> > kernel: [<ffffffff8122ce88>] ? try_to_compact_pages+0x2f1/0x648 > > kernel: [<ffffffff8122cb97>] ? compaction_zonelist_suitable+0x3a6/0x3a6 > > kernel: [<ffffffff811ef1ea>] ? get_page_from_freelist+0x2c0/0x133c > > kernel: [<ffffffff811f0350>] __alloc_pages_direct_compact+0xea/0x30d > > kernel: [<ffffffff811f0266>] ? get_page_from_freelist+0x133c/0x133c > > kernel: [<ffffffff811ee3b2>] ? drain_all_pages+0x1d6/0x205 > > kernel: [<ffffffff811f21a8>] __alloc_pages_nodemask+0x143d/0x16b6 > > kernel: [<ffffffff8111f405>...

...steady state will little free memory and 100% fragmentation. Now I see > 10-30x more memory free (read: not utilized). Order > 0 allocations > were happening rarely before, now it happens consistently from this > function. > > My suggestion above would avoid mm going through > __alloc_pages_direct_compact() and triggering the bad events above. It > will take me several days to try this experiment. My suggestion is to use a recent kernel, and/or eventually backport the mm fixes if any. order-3 allocations should not reclaim 2GB out of 8GB. There is a reason PAGE_ALLOC_COSTLY_ORDER exists and is...

...8>] try_to_compact_pages+0x2f1/0x648 kernel: [<ffffffff8122ce88>] ? try_to_compact_pages+0x2f1/0x648 kernel: [<ffffffff8122cb97>] ? compaction_zonelist_suitable+0x3a6/0x3a6 kernel: [<ffffffff811ef1ea>] ? get_page_from_freelist+0x2c0/0x133c kernel: [<ffffffff811f0350>] __alloc_pages_direct_compact+0xea/0x30d kernel: [<ffffffff811f0266>] ? get_page_from_freelist+0x133c/0x133c kernel: [<ffffffff811ee3b2>] ? drain_all_pages+0x1d6/0x205 kernel: [<ffffffff811f21a8>] __alloc_pages_nodemask+0x143d/0x16b6 kernel: [<ffffffff8111f405>] ? debug_show_all_locks+0x226/0x226 ker...

...ne+0x3e7/0x5ca Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8110c2e5>] compact_zone_order+0x94/0x9f Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8110c381>] try_to_compact_pages+0x91/0xe3 Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8146e867>] __alloc_pages_direct_compact+0xa7/0x16d Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810deea3>] __alloc_pages_nodemask+0x46a/0x77f Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81108755>] alloc_pages_current+0xbe/0xd8 Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8111c7aa>]...

...l: [<ffffffff8122ce88>] ? try_to_compact_pages+0x2f1/0x648 > > > kernel: [<ffffffff8122cb97>] ? compaction_zonelist_suitable+0x3a6/0x3a6 > > > kernel: [<ffffffff811ef1ea>] ? get_page_from_freelist+0x2c0/0x133c > > > kernel: [<ffffffff811f0350>] __alloc_pages_direct_compact+0xea/0x30d > > > kernel: [<ffffffff811f0266>] ? get_page_from_freelist+0x133c/0x133c > > > kernel: [<ffffffff811ee3b2>] ? drain_all_pages+0x1d6/0x205 > > > kernel: [<ffffffff811f21a8>] __alloc_pages_nodemask+0x143d/0x16b6 > > > kernel: [<...

...l: [<ffffffff8122ce88>] ? try_to_compact_pages+0x2f1/0x648 > > > kernel: [<ffffffff8122cb97>] ? compaction_zonelist_suitable+0x3a6/0x3a6 > > > kernel: [<ffffffff811ef1ea>] ? get_page_from_freelist+0x2c0/0x133c > > > kernel: [<ffffffff811f0350>] __alloc_pages_direct_compact+0xea/0x30d > > > kernel: [<ffffffff811f0266>] ? get_page_from_freelist+0x133c/0x133c > > > kernel: [<ffffffff811ee3b2>] ? drain_all_pages+0x1d6/0x205 > > > kernel: [<ffffffff811f21a8>] __alloc_pages_nodemask+0x143d/0x16b6 > > > kernel: [<...

...315.147550] [<ffffffff8122bcff>] ? try_to_compact_pages+0x2f1/0x648 > [ 315.147568] [<ffffffff8122ba0e>] ? compaction_zonelist_suitable+0x3a6/0x3a6 > [ 315.147589] [<ffffffff811ee129>] ? get_page_from_freelist+0x2c0/0x129a > [ 315.147608] [<ffffffff811ef1ed>] __alloc_pages_direct_compact+0xea/0x30d > [ 315.147626] [<ffffffff811ef103>] ? get_page_from_freelist+0x129a/0x129a > [ 315.147645] [<ffffffff811f0422>] __alloc_pages_nodemask+0x840/0x16b6 > [ 315.147663] [<ffffffff810dba27>] ? try_to_wake_up+0x696/0x6c8 > [ 315.149147] [<ffffffff811efb...

...315.147550] [<ffffffff8122bcff>] ? try_to_compact_pages+0x2f1/0x648 > [ 315.147568] [<ffffffff8122ba0e>] ? compaction_zonelist_suitable+0x3a6/0x3a6 > [ 315.147589] [<ffffffff811ee129>] ? get_page_from_freelist+0x2c0/0x129a > [ 315.147608] [<ffffffff811ef1ed>] __alloc_pages_direct_compact+0xea/0x30d > [ 315.147626] [<ffffffff811ef103>] ? get_page_from_freelist+0x129a/0x129a > [ 315.147645] [<ffffffff811f0422>] __alloc_pages_nodemask+0x840/0x16b6 > [ 315.147663] [<ffffffff810dba27>] ? try_to_wake_up+0x696/0x6c8 > [ 315.149147] [<ffffffff811efb...

...0000004 [54807.385539] 000000000010c0d0 ffff8800591a38b8 ffffffff81a661de ffff88005fd1c680 [54807.401978] Call Trace: [54807.418015] [<ffffffff81a6a8ba>] dump_stack+0x4f/0x84 [54807.433971] [<ffffffff81138770>] warn_alloc_failed+0xf0/0x140 [54807.449644] [<ffffffff81a661de>] ? __alloc_pages_direct_compact+0x1ac/0x1be [54807.465164] [<ffffffff8113bfaa>] __alloc_pages_nodemask+0x7aa/0x9d0 [54807.480510] [<ffffffff810ed069>] ? trace_hardirqs_off_caller+0xb9/0x160 [54807.495622] [<ffffffff81175277>] alloc_pages_current+0xb7/0x180 [54807.510530] [<ffffffff81138059>] __get_free...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot

Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup: kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03

Hey Jens, Please in your spare time (if there is such a thing at a conference) pull this branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10 for your v3.10 branch. Sorry for being so late with this. <blurb> It has the ''feature-max-indirect-segments'' implemented in both backend and frontend. The current problem with the backend and