Re: What would cause freezes that numlock fixes?

From: Trenton D. Adams
Date: Sun Apr 05 2009 - 22:36:44 EST


Your pressing of numlock thing is odd to me. But as for the rest...

The kernel folks are trying to work on these issues already. There
are many similar reports, including from myself. Here are some things
to try.

echo "1" > /proc/sys/vm/dirty_ratio
echo "2" > /proc/sys/vm/dirty_background_ratio

This sets the amount of dirty memory, in percentage of memory in the
system, before a process or the pdflush background daemon start
writing out dirty data. Dirty data is data that has not been
committed to disk yet.

See /usr/src/linux/Documentation/sysctl/vm.txt for more information,
if you have the kernel sources installed.

If you switched to 2.6.29, it gets even more tuneable. 2.6.29 adds
"dirty_bytes" and "dirty_background_bytes" respectively. They
override the "ratio" versions. For me, that is important, as I find
that anything beyond 5M or so produces really bad hangs.

Another thing you can do is force your ext3 filesystem to mount with
data=writeback. I just issued the following command, and then
rebooted...
tune2fs -o journal_data_writeback /dev/s/sys

tune2fs -l /dev/s/sys | grep journal

If you want to switch it back to the default, just issue...
tune2fs -o journal_data_ordered /dev/s/sys

But yes, using ext4 helps the issue as well. I have a hunch that the
ext3 issues are just a tangent issue to the real problem, as I never
had a problem before 2.6.18. It used to be that I could run a heavy
dd without any problems at all. But, alas, I don't know enough about
the kernel source to look into it myself, nor do I have the time
learn.

Using the "writeback" option above, I am finding that I can set my
dirty_ratio to 40, and not have many problems. I have not yet tried
ext4, but I may in the future.

On Sun, Apr 5, 2009 at 4:57 PM, John Moser <john.r.moser@xxxxxxxxx> wrote:
> I'm using Ubuntu's current beta 9.04 and it's having issues.  I think it's a
> kernel thing, but I have no debug data or anything; if anyone has any
> insight as to what might be happening I'd like that.  I can't do debugging
> here (unless they package a debugging kernel).
>
> I'm using what Ubuntu calls "2.6.28-11.40" "generic", on x86-64, with the
> uname:
>
> Linux icebox 2.6.28-11-generic #40-Ubuntu SMP Fri Apr 3 17:39:41 UTC 2009
> x86_64 GNU/Linux
>
>
> What's happening is this:
>
> I noticed immediately that the system lags a lot, especially when under
> load, sometimes when not under load.  I figured bad scheduling at first.
> Switching to ext4 helped.
>
> Oddly enough, switching to elevator=as instead of CFQ helps as well. This
> helps, but doesn't fix the problem.  So, I'm guessing there's no bug in CFQ
> or EXT3, but running these rather than AS and EXT4 aggravates symptoms.
>
> Occasionally almost everything in X will freeze.  Some programs (like, a
> terminal) still work until they try to access the disk (say, if I run a
> command, bash hangs).  I eventually had this happen while top was running
> and noticed stuff going into state D and staying there for up to 5 minutes,
> while the disk halts.  I can still shift between virtual desktops in Gnome,
> with the stipulation that every application is frozen and I can't start any
> others.
>
> At some point (today, actually) I found a workaround.  When applications--
> either one, or all of them-- start to freeze, if I press (specifically) the
> Num Lock key, everything suddenly wakes up.  Disk starts cranking like
> crazy, windows redraw, and I assume everything instantly comes back out of D
> state.
>
> Just Num Lock.  Not A, not CTRL, not Tab.  Just Num Lock.
>
> Anyone have any guesses?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/