lkml.org 
[lkml]   [2015]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Dirty pages underflow on 3.14.23
On Mon, Jan 05, 2015 at 06:05:59PM -0500, Mikulas Patocka wrote:
> Hi
>
> I would like to report a memory management bug where the dirty pages count
> underflowed.
>
> It happened after some time that the Dirty pages count underflowed, as can
> be seen in /proc/meminfo. The underflow condition was persistent,
> /proc/meminfo was showing the big value even when the system was
> completely idle. The counter never returned to zero.
>
> The system didn't crash, but it became very slow - because of the big
> value in the "Dirty" field, lazy writing was not working anymore, any
> process that created a dirty page triggered immediate writeback, which
> slowed down the system very much. The only fix was to reboot the machine.
>
> The kernel version where this happened is 3.14.23. The kernel is compiled
> without SMP and with peemption. The system is single-core 32-bit x86.
>
> The bug probably happened during git pull or apt-get update, though one
> can't be sure that these commands caused it.
>
> I see that 3.14.24 containes some fix for underflow (commit
> 6619741f17f541113a02c30f22a9ca22e32c9546, upstream commit
> abe5f972912d086c080be4bde67750630b6fb38b), but it doesn't seem that that
> commit fixes this condition. If you have a commit that could fix this, say
> it.

That's an unrelated counter, but there is a known dirty underflow
problem that was addressed in 87a7e00b206a ("mm: protect
set_page_dirty() from ongoing truncation"). It should make it into
the stable kernels in the near future. Can you reproduce this issue?

Thanks,
Johannes


\
 
 \ /
  Last update: 2015-01-06 16:21    [W:0.047 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site