Re: [BUG] page allocation failure reading procfs ipv6 configuration files with cgroups

2021-02-22 Thread Peter Geis
y ten minutes I was greeted with the following splat in the kernel log: > > > > [2122311.383389] warn_alloc: 3 callbacks suppressed > > [2122311.383403] cat: page allocation failure: order:5, > > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), > > nodemask=(null),cpuset=lxc

Re: [BUG] page allocation failure reading procfs ipv6 configuration files with cgroups

2021-02-20 Thread Matthew Wilcox
383389] warn_alloc: 3 callbacks suppressed > [2122311.383403] cat: page allocation failure: order:5, > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), > nodemask=(null),cpuset=lxc.payload.openwrt,mems_allowed=0 You want this patch: https://lore.kernel.org/linux-fsdevel/6345270a2c1160b89dd5e

[BUG] page allocation failure reading procfs ipv6 configuration files with cgroups

2021-02-20 Thread Peter Geis
Good Afternoon, I have been tracking down a regular bug that triggers when running OpenWRT in a lxd container. Every ten minutes I was greeted with the following splat in the kernel log: [2122311.383389] warn_alloc: 3 callbacks suppressed [2122311.383403] cat: page allocation failure: order:5

Re: [bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]

2021-02-09 Thread Mikhail Gavrilov
On Mon, 8 Feb 2021 at 14:18, Christian König wrote: > > Are the other problems gone as well? > And yes and no. The issue with monitor turns off was gone after rc6 (git3aaf0a27ffc2) But both traces 1) BUG: sleeping function called from invalid context at include/linux/sched/mm.h:196 (kernel 5.11 s

Re: [bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]

2021-02-08 Thread Christian König
Am 06.02.21 um 19:17 schrieb Mikhail Gavrilov: On Sun, 31 Jan 2021 at 22:22, Christian König wrote: Yeah, known issue. I already pushed Michel's fix to drm-misc-fixes. Should land in the next -rc by the weekend. Regards, Christian. I checked this patch [1] for several days. And I can confirm

Re: [bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]

2021-02-06 Thread Mikhail Gavrilov
On Sun, 31 Jan 2021 at 22:22, Christian König wrote: > > > Yeah, known issue. I already pushed Michel's fix to drm-misc-fixes. > Should land in the next -rc by the weekend. > > Regards, > Christian. I checked this patch [1] for several days. And I can confirm that the reported issue was gone. [1

Re: [bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]

2021-01-31 Thread Christian König
Am 31.01.21 um 02:03 schrieb David Rientjes: On Sat, 30 Jan 2021, David Rientjes wrote: On Sun, 31 Jan 2021, Mikhail Gavrilov wrote: The 5.11-rc5 (git 76c057c84d28) brought a new issue. Now the kernel log is flooded with the message "page allocation failure". Trace: msedge

Re: [bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]

2021-01-30 Thread David Rientjes
On Sat, 30 Jan 2021, David Rientjes wrote: > On Sun, 31 Jan 2021, Mikhail Gavrilov wrote: > > > The 5.11-rc5 (git 76c057c84d28) brought a new issue. > > Now the kernel log is flooded with the message "page allocation failure". > > > > Trace: > >

Re: [bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]

2021-01-30 Thread David Rientjes
On Sun, 31 Jan 2021, Mikhail Gavrilov wrote: > The 5.11-rc5 (git 76c057c84d28) brought a new issue. > Now the kernel log is flooded with the message "page allocation failure". > > Trace: > msedge:cs0: page allocation failure: order:10, Order-10, wow! ttm_pool_alloc() w

[bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]

2021-01-30 Thread Mikhail Gavrilov
The 5.11-rc5 (git 76c057c84d28) brought a new issue. Now the kernel log is flooded with the message "page allocation failure". Trace: msedge:cs0: page allocation failure: order:10, mode:0x190cc2(GFP_HIGHUSER|__GFP_NORETRY|__GFP_NOMEMALLOC), nodemask=(null),cpuset=/,mems_allowed=0 C

Re: [bugreport] [5.10-rc1] Oops: 0000 [#1] SMP NOPTI bug which always starts as page allocation failure

2020-11-04 Thread Alex Deucher
On Tue, Nov 3, 2020 at 4:05 PM Mikhail Gavrilov wrote: > > Hi folks. > I observed hard reproductible the set of bugs. > It always started as > 1) kworker/u64:2: page allocation failure: order:5, > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), > nodemask=(null),cp

[bugreport] [5.10-rc1] Oops: 0000 [#1] SMP NOPTI bug which always starts as page allocation failure

2020-11-03 Thread Mikhail Gavrilov
Hi folks. I observed hard reproductible the set of bugs. It always started as 1) kworker/u64:2: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 Continious as: 2) WARNING: CPU: 21 PID: 806649 at drivers/gpu/drm/amd/amdgpu

RE: [External] Re: linux kernel page allocation failure and tuning of page cache

2019-06-03 Thread Nagal, Amit UTC CCS
it firstly chrt -r 20 and then changed it later to renice -n -20) I observed lru-add-drain , writeback threads were executing at normal priority . what I mean above is 2 separate iterations for process priority settings ( 1st iteration :: chrt -r 20 , 2nd iteration : renice -n -20 , there was no iteration in which both chrt and renice were used together) . although in both priority settings , we got the page allocation failure problem .

RE: [External] Re: linux kernel page allocation failure and tuning of page cache

2019-06-03 Thread Nagal, Amit UTC CCS
From: Matthew Wilcox [mailto:wi...@infradead.org] Sent: Monday, June 3, 2019 5:42 PM To: Nagal, Amit UTC CCS On Mon, Jun 03, 2019 at 05:30:57AM +, Nagal, Amit UTC CCS wrote: > > [ 776.174308] Mem-Info: > > [ 776.176650] active_anon:2037 inactive_anon:23 isolated_anon:0 [ >

Re: [External] Re: linux kernel page allocation failure and tuning of page cache

2019-06-03 Thread Matthew Wilcox
On Mon, Jun 03, 2019 at 05:30:57AM +, Nagal, Amit UTC CCS wrote: > > [ 776.174308] Mem-Info: > > [ 776.176650] active_anon:2037 inactive_anon:23 isolated_anon:0 [ > > 776.176650] active_file:2636 inactive_file:7391 isolated_file:32 [ > > 776.176650] unevictable:0 dirty:13

RE: [External] Re: linux kernel page allocation failure and tuning of page cache

2019-06-03 Thread Nagal, Amit UTC CCS
rg Subject: [External] Re: linux kernel page allocation failure and tuning of page cache > 1) the platform is low memory platform having memory 64MB. > > 2) we are doing around 45MB TCP data transfer from PC to target using netcat > utility .On Target , a process receives data over socket and

RE: [External] Re: linux kernel page allocation failure and tuning of page cache

2019-06-02 Thread Nagal, Amit UTC CCS
-Original Message- From: Alexander Duyck [mailto:alexander.du...@gmail.com] Sent: Saturday, June 1, 2019 2:57 AM To: Nagal, Amit UTC CCS Cc: linux-kernel@vger.kernel.org; linux...@kvack.org; CHAWLA, RITU UTC CCS Subject: [External] Re: linux kernel page allocation failure and tuning of

RE: [External] Re: linux kernel page allocation failure and tuning of page cache

2019-06-02 Thread Nagal, Amit UTC CCS
think your network is faster than your disk ... Ok . I need to check it . But how does this affect page reclaim procedure . > 5) sometimes , we observed kernel memory getting exhausted as page allocation > failure happens in kernel with the backtrace is printed below : > # [ 775.9

linux kernel page allocation failure and tuning of page reclaim procedure

2019-05-31 Thread amit nagal
1245 Swap: 0 0 0 5) sometimes , we observed kernel memory getting exhausted as page allocation failure happens in kernel with the backtrace as printed below in point 7 ): 6) we have certain questions as below : a) how the kernel memor

Re: linux kernel page allocation failure and tuning of page cache

2019-05-31 Thread Alexander Duyck
buffers cached > Mem: 5756 1 >02 42 > -/+ buffers/cache: 1245 > Swap: 0 0 0 > > 5) sometimes , we observe

Re: linux kernel page allocation failure and tuning of page cache

2019-05-31 Thread Matthew Wilcox
r disk ... > 5) sometimes , we observed kernel memory getting exhausted as page allocation > failure happens in kernel with the backtrace is printed below : > # [ 775.947949] nc.traditional: page allocation failure: order:0, > mode:0x2080020(GFP_ATOMIC) We're in the soft int

linux kernel page allocation failure and tuning of page cache

2019-05-31 Thread Nagal, Amit UTC CCS
1245 Swap: 0 0 0 5) sometimes , we observed kernel memory getting exhausted as page allocation failure happens in kernel with the backtrace is printed below : # [ 775.947949] nc.traditional: page allocation failure: o

Re: Page Allocation Failure and Page allocation stalls

2019-05-09 Thread Pankaj Suryawanshi
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

Re: Page Allocation Failure and Page allocation stalls

2019-05-03 Thread Pankaj Suryawanshi
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: orde

Re: Page-allocation-failure

2019-03-28 Thread Pankaj Suryawanshi
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

Re: Page-allocation-failure

2019-03-28 Thread Pankaj Suryawanshi
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

Page-allocation-failure

2019-03-28 Thread Pankaj Suryawanshi
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

[nfsd] page allocation failure -> kernel oops, even local fs hangs.

2018-07-04 Thread Ian Kumlien
ccurs, the local filesystem is just as inaccessible as trying to use it remotely - i couldn't find any change that looked related to it in v4.18-rc3 so here goes: (the same report is attached as well) [1609167.131537] nfsd: page allocation failure: order:8, mode:0x14000c0(GFP_KERNEL), node

Re: [dummy_stm_init] swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)

2018-04-25 Thread Alexander Shishkin
ial: probe of fake-design-for-testing-f001 > > > > > failed with error -95 > > > > > [ 75.044323] fmc fake-design-for-testing-f001: Driver has no ID: > > > > > matches all > > > > > [ 75.045644] fmc_chardev fake-desig

Re: [dummy_stm_init] swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)

2018-04-24 Thread Kirill A. Shutemov
40995] fmc fake-design-for-testing-f001: Driver has no ID: > > > > matches all > > > > [ 75.042509] fmc_trivial: probe of fake-design-for-testing-f001 > > > > failed with error -95 > > > > [ 75.044323] fmc fake-design-for-testing-f001: Driver h

Re: [dummy_stm_init] swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)

2018-04-22 Thread Michal Hocko
ake-design-for-testing-f001 failed > > > with error -95 > > > [ 75.044323] fmc fake-design-for-testing-f001: Driver has no ID: > > > matches all > > > [ 75.045644] fmc_chardev fake-design-for-testing-f001: Created misc > > > device &q

Re: [dummy_stm_init] swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)

2018-04-22 Thread Kirill A. Shutemov
D: matches > > all > > [ 75.045644] fmc_chardev fake-design-for-testing-f001: Created misc > > device "fake-design-for-testing-f001" > > [ 75.061570] swapper/0: page allocation failure: order:9, > > mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null) >

Re: [dummy_stm_init] swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)

2018-04-19 Thread Alexander Shishkin
D: matches > > all > > [ 75.045644] fmc_chardev fake-design-for-testing-f001: Created misc > > device "fake-design-for-testing-f001" > > [ 75.061570] swapper/0: page allocation failure: order:9, > > mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null) >

Re: [dummy_stm_init] swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)

2018-04-18 Thread Michal Hocko
ial: probe of fake-design-for-testing-f001 failed with > error -95 > [ 75.044323] fmc fake-design-for-testing-f001: Driver has no ID: matches all > [ 75.045644] fmc_chardev fake-design-for-testing-f001: Created misc device > "fake-design-for-testing-f001" > [ 75.061

page allocation failure: order:5 in fbcon_init

2017-12-18 Thread Ivan Kozik
Hello, I observed this page allocation failure in fbcon, while copying files from one XFS filesystem to another. As far as I know, there wasn't anything else unusual going on at the time. The system uptime was about a day. After the allocation failure, I could not allocate any more ttys

Re: dd: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null)

2017-11-30 Thread Michal Hocko
On Thu 30-11-17 22:01:03, Wu Fengguang wrote: > On Thu, Nov 30, 2017 at 02:50:16PM +0100, Michal Hocko wrote: > > On Thu 30-11-17 21:38:40, Wu Fengguang wrote: > > > Hello, > > > > > > It looks like a regression in 4.15.0-rc1 -- the test case simply run a > > > set of parallel dd's and there seems

Re: dd: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null)

2017-11-30 Thread Fengguang Wu
On Thu, Nov 30, 2017 at 10:08:04PM +0800, Fengguang Wu wrote: [ 78.848629] dd: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null) [ 78.857841] dd cpuset=/ mems_allowed=0-1 [ 78.862502] CPU: 0 PID: 6131 Comm: dd Tainted: G O 4.15.0-rc1 #1

Re: dd: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null)

2017-11-30 Thread Fengguang Wu
[ 78.848629] dd: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null) [ 78.857841] dd cpuset=/ mems_allowed=0-1 [ 78.862502] CPU: 0 PID: 6131 Comm: dd Tainted: G O 4.15.0-rc1 #1 [ 78.870437] Call Trace: [ 78.873610] [ 78.876342] dump_stack

Re: dd: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null)

2017-11-30 Thread Fengguang Wu
ivers rely on atomic allocations. I just wonder if any changes make the pressure more tight than before. It may not even be a MM change -- in theory drivers might also use atomic allocations more aggressively than before. [...] [ 71.088242] dd: page allocation failure: order:0, mode:0x10

Re: dd: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null)

2017-11-30 Thread Michal Hocko
. So the failure really depends on the state of the free memory and that can vary between runs depending on timing I guess. So I am not really sure this is a regression. But maybe there is something reclaim related going on here. [...] > [ 71.088242] dd: page allocation failure: order:0, &

Re: RFH: virnet: page allocation failure: order:0

2016-09-20 Thread Philipp Hahn
Hello, Am 15.08.2016 um 15:26 schrieb Philipp Hahn: > this Sunday one of our virtual servers running linux-4.1.16 inside > OpenStack using qemu "crashed" while doing a backup using rsync to a > slow NFS server. This happened again last weekend, with the same stack trace: >> Call Trace: >>[]

virnet: page allocation failure: order:0

2016-08-15 Thread Philipp Hahn
llwoing order=0 allocation failed: > swapper/0: page allocation failure: order:0, mode:0x120 4KiB src/extern/linux/include/linux/gfp.h: 18 #define ___GFP_HIGH»»···0x20u 21 #define ___GFP_COLD»»···0x100u 72 #define __GFP_HIGH»·((__force gfp_t)___GFP_HIGH)»···/* Should access emergency pools?

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-28 Thread Michal Hocko
On Thu 28-07-16 15:50:32, Xishi Qiu wrote: > On 2016/7/20 15:47, Michal Hocko wrote: > > > On Wed 20-07-16 09:33:30, Yisheng Xie wrote: > >> > >> > >> On 2016/7/19 22:14, Vlastimil Babka wrote: > >>> On 07/19/2016 03:48 PM, Xishi Qiu wrote: > > [...] > mode:0x2000d1 means it expects to alloc

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-28 Thread Xishi Qiu
On 2016/7/20 15:47, Michal Hocko wrote: > On Wed 20-07-16 09:33:30, Yisheng Xie wrote: >> >> >> On 2016/7/19 22:14, Vlastimil Babka wrote: >>> On 07/19/2016 03:48 PM, Xishi Qiu wrote: > [...] mode:0x2000d1 means it expects to alloc from zone_dma, (on arm64 zone_dma is 0-4G) >>> >>> Yes,

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-20 Thread Michal Hocko
On Wed 20-07-16 09:33:30, Yisheng Xie wrote: > > > On 2016/7/19 22:14, Vlastimil Babka wrote: > > On 07/19/2016 03:48 PM, Xishi Qiu wrote: [...] > >> mode:0x2000d1 means it expects to alloc from zone_dma, (on arm64 zone_dma > >> is 0-4G) > > > > Yes, but I don't see where the __GFP_DMA comes fr

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Yisheng Xie
On 2016/7/19 22:14, Vlastimil Babka wrote: > On 07/19/2016 03:48 PM, Xishi Qiu wrote: >> On 2016/7/19 21:17, Vlastimil Babka wrote: >> >>> On 07/19/2016 02:43 PM, Yisheng Xie wrote: >>>> hi all, >>>> I'm getting a 2-order page allocation

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Vlastimil Babka
On 07/19/2016 03:48 PM, Xishi Qiu wrote: On 2016/7/19 21:17, Vlastimil Babka wrote: On 07/19/2016 02:43 PM, Yisheng Xie wrote: hi all, I'm getting a 2-order page allocation failure problem on 4.1.18. From the Mem-info, it seems the system have much zero order free pages which can be use

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Xishi Qiu
On 2016/7/19 21:17, Vlastimil Babka wrote: > On 07/19/2016 02:43 PM, Yisheng Xie wrote: >> hi all, >> I'm getting a 2-order page allocation failure problem on 4.1.18. >> From the Mem-info, it seems the system have much zero order free pages which >> can be used

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Vlastimil Babka
On 07/19/2016 02:43 PM, Yisheng Xie wrote: hi all, I'm getting a 2-order page allocation failure problem on 4.1.18. From the Mem-info, it seems the system have much zero order free pages which can be used for memory compaction. Is it possible that the memory compacted by current process us

[Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Yisheng Xie
hi all, I'm getting a 2-order page allocation failure problem on 4.1.18. >From the Mem-info, it seems the system have much zero order free pages which >can be used for memory compaction. Is it possible that the memory compacted by current process used by other process soon, which

Re: uas: order 7 page allocation failure in init_tag_map()

2016-04-24 Thread Hans de Goede
Hi, On 23-04-16 23:10, Johannes Stezenbach wrote: Hi, I bought a new backup disk which turned out to be UAS capable, but when I plugged it in I got an order 7 page allocation failure. My hunch is that the .can_queue = 65536 in drivers/usb/storage/uas.c is much too large. Maybe 256 would be a

uas: order 7 page allocation failure in init_tag_map()

2016-04-23 Thread Johannes Stezenbach
Hi, I bought a new backup disk which turned out to be UAS capable, but when I plugged it in I got an order 7 page allocation failure. My hunch is that the .can_queue = 65536 in drivers/usb/storage/uas.c is much too large. Maybe 256 would be a pratical value that matches the capabilities of

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-23 Thread Sergey Senozhatsky
On (11/23/15 16:43), Sergey Senozhatsky wrote: [..] > agree. we also would want to switch from vzalloc() to > __vmalloc_node_flags(size, NUMA_NO_NODE, > GFP_NOIO | __GFP_HIGHMEM | __GFP_ZERO) [..] > > So, Kyeongdon's patch will remove warning overhead and likely to > >

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-22 Thread Sergey Senozhatsky
On (11/23/15 13:18), Minchan Kim wrote: [..] > > https://lkml.org/lkml/2015/6/16/465 > > Sorry, I have missed that. > It's worth to fix that you proved it that could happen. > But when I read your patch, GFP_NOIO instead GFP_NOFS would > better way. Could you resend it? no problem. agree. we als

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-22 Thread Minchan Kim
New thread On Mon, Nov 23, 2015 at 12:14:00PM +0900, Sergey Senozhatsky wrote: > Hello, > > On (11/23/15 11:15), Minchan Kim wrote: > [..] > > > static void *zcomp_lz4_create(void) > > > { > > > - return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL); > > > + void *ret; > > > + > > > + ret = kzalloc(LZ4

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-22 Thread Sergey Senozhatsky
On (11/23/15 12:14), Sergey Senozhatsky wrote: > > yes, GFP_KERNEL looks a bit fragile to me too. And may be zcomp_strm_alloc() > and comp->backend->create() deserve GFP_NOFS. I believe I sent a patch doing > this a while ago: https://lkml.org/lkml/2015/6/16/465 > perhaps just __GFP_RECLAIM (GFP_

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-22 Thread Sergey Senozhatsky
Hello, On (11/23/15 11:15), Minchan Kim wrote: [..] > > static void *zcomp_lz4_create(void) > > { > > - return kzalloc(LZ4_MEM_COMPRESS, GFP_KERNEL); > > + void *ret; > > + > > + ret = kzalloc(LZ4_MEM_COMPRESS, > > + __GFP_NORETRY|__GFP_NOWARN|__GFP_NOMEMALLOC); > > + i

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-22 Thread Minchan Kim
Hello, On Fri, Nov 20, 2015 at 07:02:44PM +0900, Kyeongdon Kim wrote: > When we're using LZ4 multi compression streams for zram swap, > we found out page allocation failure message in system running test. > That was not only once, but a few(2 - 5 times per test). > Also, some f

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-21 Thread Sergey Senozhatsky
On (11/21/15 11:15), Sergey Senozhatsky wrote: [..] > > with the only nit that the subject should be "try kmalloc() before vmalloc()" > or similar, not "prevent page allocation failure", I think. > Oh, and one more thing > static void zcomp_lz4_destro

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-20 Thread Sergey Senozhatsky
On (11/21/15 11:10), Sergey Senozhatsky wrote: > Cc Andrew > > On (11/20/15 19:02), Kyeongdon Kim wrote: > > When we're using LZ4 multi compression streams for zram swap, > > we found out page allocation failure message in system running test. > > That was not only

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-20 Thread Sergey Senozhatsky
Cc Andrew On (11/20/15 19:02), Kyeongdon Kim wrote: > When we're using LZ4 multi compression streams for zram swap, > we found out page allocation failure message in system running test. > That was not only once, but a few(2 - 5 times per test). > Also, some failure cases

[PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-20 Thread Kyeongdon Kim
When we're using LZ4 multi compression streams for zram swap, we found out page allocation failure message in system running test. That was not only once, but a few(2 - 5 times per test). Also, some failure cases were continually occurring to try allocation order 3. In order to make par

Re: [PATCH] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-19 Thread Sergey Senozhatsky
Hello, On (11/20/15 01:00), Minchan Kim wrote: [..] > [1] 42614b05825, crypto: lzo - try kmalloc() before vmalloc() > So, could you make vmalloc as fallback of kmalloc? Looks good to me. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a messa

Re: [PATCH] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-19 Thread Sergey Senozhatsky
Hello, On (11/19/15 22:49), kyeongdon.kim wrote: [..] > I know what you mean (streams are not free). > First of all, I'm sorry I would have to tell you why I try this patch. nothing to be sorry about. > When we're using LZ4 multi stream for zram swap, I found out this > allocation failure messag

Re: Re: [PATCH] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-19 Thread kyeongdon.kim
Hello, On 2015-11-19 오후 6:45, Sergey Senozhatsky wrote: > Hello, > > On (11/19/15 15:54), kyeongdon.kim wrote: >> When we use lzo/lz4 multi compression streams for zram, >> we might face page allocation failure. In order to make parallel >> compression private data, we

Re: [PATCH] zram: Prevent page allocation failure during zcomp_strm_alloc

2015-11-19 Thread Sergey Senozhatsky
Hello, On (11/19/15 15:54), kyeongdon.kim wrote: > When we use lzo/lz4 multi compression streams for zram, > we might face page allocation failure. In order to make parallel > compression private data, we should call kzalloc() with order 2/3 > in runtime. But if there is no order 2/3

[PATCH 3.12 72/83] kvm: avoid page allocation failure in kvm_set_memory_region()

2015-04-27 Thread Jiri Slaby
From: Igor Mammedov 3.12-stable review patch. If anyone has any objections, please let me know. === commit 744961341d472db6272ed9b42319a90f5a2aa7c4 upstream. KVM guest can fail to startup with following trace on host: qemu-system-x86: page allocation failure: order:4, mode

[PATCH 3.16.y-ckt 136/144] kvm: avoid page allocation failure in kvm_set_memory_region()

2015-04-21 Thread Luis Henriques
3.16.7-ckt10 -stable review patch. If anyone has any objections, please let me know. -- From: Igor Mammedov commit 744961341d472db6272ed9b42319a90f5a2aa7c4 upstream. KVM guest can fail to startup with following trace on host: qemu-system-x86: page allocation failure: order

[PATCH 3.19 101/101] kvm: avoid page allocation failure in kvm_set_memory_region()

2015-04-17 Thread Greg Kroah-Hartman
3.19-stable review patch. If anyone has any objections, please let me know. -- From: Igor Mammedov commit 744961341d472db6272ed9b42319a90f5a2aa7c4 upstream. KVM guest can fail to startup with following trace on host: qemu-system-x86: page allocation failure: order:4, mode

Re: [PATCH v2] kvm: avoid page allocation failure in kvm_set_memory_region()

2015-03-31 Thread Igor Mammedov
On Fri, 20 Mar 2015 12:21:37 + Igor Mammedov wrote: > KVM guest can fail to startup with following trace on host: > > qemu-system-x86: page allocation failure: order:4, mode:0x40d0 > Call Trace: > dump_stack+0x47/0x67 > warn_alloc_failed+0xee/0x150 > __alloc_pages

[PATCH v2] kvm: avoid page allocation failure in kvm_set_memory_region()

2015-03-20 Thread Igor Mammedov
KVM guest can fail to startup with following trace on host: qemu-system-x86: page allocation failure: order:4, mode:0x40d0 Call Trace: dump_stack+0x47/0x67 warn_alloc_failed+0xee/0x150 __alloc_pages_direct_compact+0x14a/0x150 __alloc_pages_nodemask+0x776/0xb80 alloc_kmem_pages+0x3a

Re: [LKP] [fs] swapper/0: page allocation failure: order:0, mode:0x50

2015-01-27 Thread Paul Moore
On Tuesday, January 27, 2015 02:59:45 PM Huang Ying wrote: > FYI, we noticed the below changes on > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > commit 6aaca9bab6116a2b392e7a07b5ff209741bc248f ("fs: create proper filename > objects using getname_kernel()") > > Ther

[PATCH v3 7/7] brd: Return -ENOSPC rather than -ENOMEM on page allocation failure

2014-04-13 Thread Matthew Wilcox
brd is effectively a thinly provisioned device. Thinly provisioned devices return -ENOSPC when they can't write a new block. -ENOMEM is an implementation detail that callers shouldn't know. Acked-by: Dave Chinner Signed-off-by: Matthew Wilcox --- drivers/block/brd.c | 6 +++--- 1 file changed

Re: btrfs-rmw-2: page allocation failure: order:1, mode:0x8020

2014-03-29 Thread Marc MERLIN
e are the logs. Is this anything known or with a possible workaround? Thanks, Marc btrfs-rmw-2: page allocation failure: order:1, mode:0x8020 CPU: 1 PID: 12499 Comm: btrfs-rmw-2 Not tainted 3.14.0-rc5-amd64-i915-preempt-20140216c #1 Hardware name: System manufacturer P5KC/P5KC, BIOS 050205/24

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0

2013-05-06 Thread Roger Pau Monné
/scm/linux/kernel/git/konrad/xen.git >>>>> stable/for-jens-3.10 >>>> > >>> .. snip.. >>>> Hi Konrad / Roger, >>>> >>>> I tried this pull on top of latest Linus latest linux-3.9 tree, but >>>> although it se

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0

2013-05-04 Thread Sander Eikelenboom
p.. >>> Hi Konrad / Roger, >>> >>> I tried this pull on top of latest Linus latest linux-3.9 tree, but >>> although it seems to boot and work fine at first, i seem to get trouble >>> after running for about a day. >>> Without this pull it runs

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0

2013-04-29 Thread Jens Axboe
atest linux-3.9 tree, but > > although it seems to boot and work fine at first, i seem to get trouble > > after running for about a day. > > Without this pull it runs fine for several days. > .. snipp. > > > [18496.013743] xenwatch: page allocation failure: order:7,

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0

2013-04-29 Thread Sander Eikelenboom
t although >> it seems to boot and work fine at first, i seem to get trouble after running >> for about a day. >> Without this pull it runs fine for several days. > .. snipp. >> [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0 >&g

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0

2013-04-29 Thread Konrad Rzeszutek Wilk
out a day. > Without this pull it runs fine for several days. .. snipp. > [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0 > [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ #1 > [18496.049897] Call Trace: > [18496.067674] [] war

Re: Page allocation failure on v3.8-rc5

2013-01-31 Thread Ming Lei
On Fri, Feb 1, 2013 at 7:43 AM, Andrew Morton wrote: > On Wed, 30 Jan 2013 19:53:22 +0800 > Ming Lei wrote: > >> The allocation failure is caused by the big sizeof(struct parsed_partitions), >> which is 64K in my 32bit box, > > Geeze. > > We could fix that nicely by making parsed_partitions.parts

Re: Page allocation failure on v3.8-rc5

2013-01-31 Thread Andrew Morton
On Wed, 30 Jan 2013 19:53:22 +0800 Ming Lei wrote: > The allocation failure is caused by the big sizeof(struct parsed_partitions), > which is 64K in my 32bit box, Geeze. We could fix that nicely by making parsed_partitions.parts an array of pointers to a single `struct parsed_partition' and all

Re: Page allocation failure on v3.8-rc5

2013-01-30 Thread Ming Lei
On Mon, Jan 28, 2013 at 5:10 PM, Felipe Balbi wrote: > Hi, > > The following page allocation failure triggers sometimes when I plug my > memory card reader on a USB port. > > > [850845.928795] usb 1-4: new high-speed USB device number 48 using ehci-pci > [850846.300702]

Re: [2.6.25-rc2, 2.6.24-rc8] page allocation failure...

2008-02-24 Thread Daniel J Blueman
00e after a few days' uptime, so all looks well... Thanks again, Daniel > >> It's clearly non-fatal, but then do we expect it to occur? > >> > >> Daniel > >> > >> --- [dmesg] > >> > >> [ 1250.822786]

Re: [2.6.25-rc2, 2.6.24-rc8] page allocation failure...

2008-02-19 Thread Kok, Auke
1000 dumps here... >> It's clearly non-fatal, but then do we expect it to occur? >> >> Daniel >> >> --- [dmesg] >> >> [ 1250.822786] swapper: page allocation failure. order:3, mode:0x4020 >> [ 1250.822786] Pid: 0, comm: swapper Not tainted 2.6.2

Re: [2.6.25-rc2, 2.6.24-rc8] page allocation failure...

2008-02-18 Thread Andrew Morton
On Sun, 17 Feb 2008 13:20:59 + "Daniel J Blueman" <[EMAIL PROTECTED]> wrote: > I'm still hitting this with e1000e on 2.6.25-rc2, 10 times again. > > It's clearly non-fatal, but then do we expect it to occur? > > Daniel > > --- [dmesg] >

Re: [2.6.25-rc2, 2.6.24-rc8] page allocation failure...

2008-02-17 Thread Daniel J Blueman
I'm still hitting this with e1000e on 2.6.25-rc2, 10 times again. It's clearly non-fatal, but then do we expect it to occur? Daniel --- [dmesg] [ 1250.822786] swapper: page allocation failure. order:3, mode:0x4020 [ 1250.822786] Pid: 0, comm: swapper Not tainted 2.6.25-rc2-119 #2 [ 1

[2.6.24-rc8] page allocation failure...

2008-02-14 Thread Daniel J Blueman
er of times). What other information may help with this? Daniel --- dmesg swapper: page allocation failure. order:1, mode:0x4020 Pid: 0, comm: swapper Not tainted 2.6.24-rc8-117 #1 Call Trace: [] __alloc_pages+0x336/0x390 [] __netdev_alloc_skb+0x17/0x40 [] __slab_alloc+0x145/0x3d0 [] __netdev_allo

Re: 2.6.24 Page Allocation Failure

2008-02-01 Thread Mel Gorman
el configuration? Throughput when running 2.6.24 is about 40 percent > lower than when running 2.6.22.9-- surely due to these errors. > It's possible. Is there a stream of these errors coming through constantly? > Jan 29 22:13:36 master kernel: nfsd: page allocation failure. order

Re: [Myricom help #56546] Re: 2.6.24 Page Allocation Failure

2008-02-01 Thread Andrew Gallatin
AndrewL733 wrote: > The cause of this problem seems to be compiling the Myricom driver with > the ALLOC_ORDER=2 option. When I use the in-kernel driver, (1.3.2) or > recompile the Myricom 1.4.0 driver WITHOUT the option, the problem seems > to go away even after heavy hammering of the system. > >

Re: 2.6.24 Page Allocation Failure

2008-02-01 Thread AndrewL733
talled 2.6.24 and get the following errors as soon as I begin doing NFS I/O over the Myricom card. Maybe I missed something in the kernel configuration? Throughput when running 2.6.24 is about 40 percent lower than when running 2.6.22.9-- surely due to these errors. Jan 29 22:13:36 master kern

2.6.24 Page Allocation Failure

2008-01-31 Thread AndrewL733
master kernel: nfsd: page allocation failure. order:2, mode:0x4020 Jan 29 22:13:36 master kernel: Pid: 6586, comm: nfsd Not tainted 2.6.24 #1 Jan 29 22:13:36 master kernel: Jan 29 22:13:36 master kernel: Call Trace: Jan 29 22:13:36 master kernel:[__alloc_pages+822/912] __alloc_pages+0x336/0

Re: VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)

2007-11-08 Thread David Miller
From: Nick Piggin <[EMAIL PROTECTED]> Date: Thu, 8 Nov 2007 16:55:38 +1100 > But it's an order-1 allocation, which may not be available due to > fragmentation. If the user is using an MTU of only 1500 (and thus not using jumbo frames) he may be being bitten by a bug that was recently fixed by Her

Re: VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)

2007-11-08 Thread Nick Piggin
> > different machines I'm maintaining. Symptom: a page allocation failure > > > with order:1, GFP_ATOMIC, while there is plenty of memory, as it seems > > > (lots of free pages, almost no swap used) followed by a lockup > > > (everything dead). I've collec

Re: VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)

2007-11-07 Thread Frank van Maarseveen
els for me (fglrx doesn't count ;). > > > > > >One note: I suspect that reporting a GFP_ATOMIC allocation failure in an > > >network driver via that same driver (netconsole) may not be the smartest > > >thing to do and this could be responsible for the lockup

Re: VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)

2007-11-07 Thread Frank van Maarseveen
On Tue, Nov 06, 2007 at 05:13:50PM -0600, Robert Hancock wrote: > Frank van Maarseveen wrote: > >For quite some time I'm seeing occasional lockups spread over 50 different > >machines I'm maintaining. Symptom: a page allocation failure with order:1, > >GFP_ATOMIC,

Re: VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)

2007-11-07 Thread Frank van Maarseveen
On Wed, Nov 07, 2007 at 09:01:17AM +1100, Nick Piggin wrote: > On Tuesday 06 November 2007 04:42, Frank van Maarseveen wrote: > > For quite some time I'm seeing occasional lockups spread over 50 different > > machines I'm maintaining. Symptom: a page allocation failure wit

Re: VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)

2007-11-06 Thread Nick Piggin
On Tuesday 06 November 2007 04:42, Frank van Maarseveen wrote: > For quite some time I'm seeing occasional lockups spread over 50 different > machines I'm maintaining. Symptom: a page allocation failure with order:1, > GFP_ATOMIC, while there is plenty of memory, as it seems (l

Re: VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)

2007-11-06 Thread Robert Hancock
Frank van Maarseveen wrote: For quite some time I'm seeing occasional lockups spread over 50 different machines I'm maintaining. Symptom: a page allocation failure with order:1, GFP_ATOMIC, while there is plenty of memory, as it seems (lots of free pages, almost no swap used) fol

VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)

2007-11-05 Thread Frank van Maarseveen
For quite some time I'm seeing occasional lockups spread over 50 different machines I'm maintaining. Symptom: a page allocation failure with order:1, GFP_ATOMIC, while there is plenty of memory, as it seems (lots of free pages, almost no swap used) followed by a lockup (everything d

Re: Kernel 2.6.21.6:"swapper: page allocation failure. order:1, mode:0x20"

2007-10-18 Thread Nick Piggin
On Thursday 18 October 2007 16:16, Andrew A. Razdolsky wrote: > Hello! > > In attachments i did pick all info i know about this failure. Hi, Does this actually cause problems for your system? Occasional page allocation failures from interrupt context are expected. If you are getting a lot of the

  1   2   >