Break 2.4 VM in five easy steps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
First things first: 1) Please Cc: me when responding, 2) apologies for dropping any References: headers, 3) sorry for bad formatting
Quoted 12 lines · Jeffrey W. Baker
Quoted 11 lines · Derek Glidden
This isn't trying to test extreme low-memory pressure, just how the system handles recovering from going somewhat into swap, which is a real
day-to-day problem for me, because I often run a couple of apps that
most of the time live in RAM, but during heavy computation runs, can go
a couple hundred megs into swap for a few minutes at a time. Whenever
that happens, my machine always starts acting up afterwards, so I started investigating and found some really strange stuff going on.
Has anyone else noticed the difference between
dd if=/dev/zero of=bigfile bs=16384k count=1
and
dd if=/dev/zero of=bigfile bs=8k count=2048
deleting 'bigfile' each time before use? (You with lots of memory may (or may not!) want to try bs=262144k)
Once, a few months ago, I thought I traced this to the loop at line ~2597 in linux/mm/filemap.c:generic_file_write
2593 remove_suid(inode);
2594 inode->i_ctime = inode->i_mtime = CURRENT_TIME;
2595 mark_inode_dirty_sync(inode);
2596
2597 while (count) {
2598 unsigned long index, offset;
2599 char *kaddr;
2600 int deactivate = 1;...
2659
2660 if (status < 0)
2661 break;
2662 }
2663 *ppos = pos;
2664
2665 if (cached_page)
It appears to me that pseudo-spins (it *does* do useful work) in this loop for as long as there are pages available.
BTW while the big-bs dd is running, the disk is active. I assume that writes are indeed scheduled and start happening even while we're still dirtying pages?
Does this freezing effect occur on SMP machines too? Oops, had access to one until this morning :( Would an SMP box still have a 'spare' cpu which isn't dirtying pages like crazy, and can therefore do things like updating mouse cursors, etc.?
Bernd Jendrissek
P.S. here's my patch that cures this one symptom; it smells and looks ugly, I know, but at least my mouse cursor doesn't jump across the whole screen when I do the dd=torture.
I have no idea if this is right or not, whether I'm allowed to call schedule inside generic_file_write or not, etc. And the '256' is just random - small enough to let the cursor move, but large enough to do work between schedule()s.
If this solves your problem, use it; if your name is Linus or Alan, ignore or do it right please.
mm/filemap.c 2001/06/07 08:57:52 1.2 renamed from mm/filemap.c 2001/06/06 21:16:28 1.1 +5 -0
@@ -2599,6 +2599,11 @@ char *kaddr; int deactivate = 1; + /* bernd-hack: give other processes a chance to run */ + if (count % 256 == 0) { + schedule(); + } + /* * Try to find the page in the cache. If it isn't there, * allocate a free page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7H1tb/FmLrNfLpjMRAguAAJ0fYInFbAa6LjFC/CWZbRPQxzZwrwCeNqT0 /Kod15Nx7AzaM4v0WhOgp88=
=pyr6
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Brian D Heaton
Maybe i'm missing something. I just tried this (with the 262144k/1
and 128k/2048 params) and my results are within .1s of each other. This is without any special patches. Am I doing something wrong????
Oh, I don't mean the time elapsed, It's that nothing _else_ can happen while dd is hogging the kernel.
Quoted 3 lines
Oh yes -
SMP - dual PIII866/133
Yes, this is what you are doing wrong ;)
My hypothesis is that in your case, one cpu gets pegged copying pages from /dev/zero into dd's buffer, while the other cpu can do things like updating mouse cursors, run setiathome, etc.
What happens if you do *two* dd-tortures with huge buffers at the same time? And then, please don't happen to have a quad box!
I don't know if my symptom (loss of interactivity on heavy writing) is related to swapoff -a causing the same symptom on deeply-swapped boxes.
BTW keep in mind my 4-liner is based more on voodoo than on analysis.
Bernd Jendrissek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7IICU/FmLrNfLpjMRAnpTAJ48/jAFxZqfxUf2NXT0O542KDbNOwCfaoZo Q2xaNE4GBqnbn/cl2vrRxLc=
=4sGO
-----END PGP SIGNATURE-----
Hi!
Quoted 2 lines
If this solves your problem, use it; if your name is Linus or Alan, ignore or do it right please.
Well I guess you should do CONDITIONAL_SCHEDULE (if it is not defined as macro, do if (current->need_resched) schedule()).
That modulo is likely slower than dereference.
Quoted 28 lines
diff -u -r1.1 -r1.2
mm/filemap.c 2001/06/07 08:57:52 1.2 renamed from mm/filemap.c 2001/06/06 21:16:28 1.1 +5
-1@@ -2599,6 +2599,11 @@ char *kaddr; int deactivate = 1; + /* bernd-hack: give other processes a chance to run */ + if (count % 256 == 0) { + schedule(); + } + /* * Try to find the page in the cache. If it isn't there, * allocate a free page. -----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.orgiD8DBQE7H1tb/FmLrNfLpjMRAguAAJ0fYInFbAa6LjFC/CWZbRPQxzZwrwCeNqT0 /Kod15Nx7AzaM4v0WhOgp88=
=pyr6
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Quoted 3 lines · Pavel Machek
That modulo is likely slower than dereference.
Quoted 1 line
+ if (count % 256 == 0) {
You are forgetting that this case should be converted to and 255 or a plain byte reference by any optimizing compiler - and gcc surely is, on x86 this code can be reduced to around 2 cycles (Pentium: mov, or, jnz, with preceding code intertwined to cancel stalls and jnz being likely in the code buffer)...
Maciek
Quoted 8 lines · Maciej Zenczykowski
Quoted 3 lines · Pavel Machek
That modulo is likely slower than dereference.
Quoted 1 line
+ if (count % 256 == 0) {
You are forgetting that this case should be converted to and 255 or a plain byte reference by any optimizing compiler
Not relevant.
What matters is that this thing calls schedule() unconditionally every 256th time. Checking current->need_resched will only call schedule if it is needed ... not only that, but it will also call schedule FASTER if it is needed.
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...
http://www.surriel.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 9 lines · Rik van Riel
Quoted 8 lines · Maciej Zenczykowski
Quoted 3 lines · Pavel Machek
That modulo is likely slower than dereference.
Quoted 1 line
+ if (count % 256 == 0) {
You are forgetting that this case should be converted to and 255 or a plain byte reference by any optimizing compiler
You read too much into my choice - 256 is a random number ;)
Quoted 4 lines
What matters is that this thing calls
schedule()unconditionally every 256th time. Checkingcurrent->need_reschedwill only call schedule if it is needed ... not only that, but it will also call schedule FASTER if it is needed.
I will try this later today, but it seems right enough.
generic_file_write seems to do enough other work that a dereference vs. and-255 shouldn't be too bad...
Bernd Jendrissek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7Jciz/FmLrNfLpjMRAmI9AKCm2EYziCzG0qrobFooGLf3kepb/wCbBQf6 nXmD/OZNhGttwQejZtYi3ic=
=rWL2
-----END PGP SIGNATURE-----