https://bugzilla.kernel.org/show_bug.cgi?id=216007 Jan Kara (jack@xxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jack@xxxxxxx --- Comment #10 from Jan Kara (jack@xxxxxxx) --- (In reply to Peter Pavlisko from comment #6) > (In reply to Chris Murphy from comment #2) > > number of CPUs > > 1 CPU, 2 cores (Intel Celeron G1610T @ 2.30GHz) OK, not much CPU power :) > > contents of /proc/meminfo > > (at the time of iowait hangup) > > MemTotal: 3995528 kB > MemFree: 29096 kB > MemAvailable: 3749216 kB > Buffers: 19984 kB > Cached: 3556248 kB > SwapCached: 0 kB > Active: 62888 kB > Inactive: 3560968 kB > Active(anon): 272 kB > Inactive(anon): 47772 kB > Active(file): 62616 kB > Inactive(file): 3513196 kB > Unevictable: 0 kB > Mlocked: 0 kB > SwapTotal: 2097084 kB > SwapFree: 2097084 kB > Dirty: 28 kB > Writeback: 0 kB Interestingly basically no dirty memory or memory under writeback. Basically everything is in Inactive(file) list which should be very easy to reclaim. But given you say we make no progress in reclaiming memory and from the traces we see process is hung waiting for memory allocation, it may be that the page cache pages are pinned in memory by extra references or something like that. The question is what could be XFS doing that clean page cache cannot be reclaimed? I have no good answer to that... ... > 8 0 1953514584 sda > 8 1 131072 sda1 > 8 2 2097152 sda2 > 8 3 1951285336 sda3 > 8 16 1953514584 sdb > 8 17 131072 sdb1 > 8 18 2097152 sdb2 > 8 19 1951285336 sdb3 > 8 32 976762584 sdc > 8 33 976761560 sdc1 > 11 0 1048575 sr0 > 9 3 1951285248 md3 > 9 2 2097088 md2 > 9 1 131008 md1 Actually not that much overall memory compared to the disk sizes or the size of unpacked archive. You've mentioned another kernel config does not exhibit the problem. Can you perhaps post it here for comparison? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
