From: Jim Olsen <jim@browsermedia.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Which kernel fixes the VM issues?
Date: Sun, 7 Jan 2001 06:31:29 -0500 [thread overview]
Message-ID: <01010706312902.10913@jim.cyberjunkees.com> (raw)
Hi... I have a question or two that would help me clear up a bit of the fuzz
I have relating to the VM: do_try_to_free_pages issue.
I currently have a server with:
o) 1 GB RAM
o) Dual PIII 700 Processors
o) Dual EtherExpress Pro NIC's
o) RedHat 6.2 w/ 2.2.17 (No patches applied)
o) High load (HTTP, DNS, SMTP, etc)
About once a week I get the 'VM: do_try_to_free_pages ...' error and
eventually get a complete system lockup. And just this morning it locked up
again, although this time with a 'VFS: LRU block list corrupted' message in
the logs, which i'm assuming is related to the VM issue as well.
When this server started having these lockups related to the VM I researched
it, and found some messages poing to a 2.2.18pre* patch available to fix this
issue, and also later down the road that the patch was accepted into the
2.2.18 final.
In following this mailing list, though, I have seen that certain people are
still having problems with the VM while running 2.2.18, although it seems to
be relegated only to those people who might be running ReiserFS. The fix, it
seems, for people with 2.2.18+ReiserFS is to get latest 2.2.19pre*.
My question is, exactly which kernel should I use in order to rid my server
of this VM issue? I'm uncomfortable (and always have been) with running pre*
kernels on production machines, so i'd like to stick with 2.2.18, but I would
like to know if it truly does fix the problem(s) with the VM. If I need to,
though, I will (hesitantly) put a 2.2.19pre* kernel on the box.
Also, I would like to know if the VM problems with 2.2.18+ReiserFS are
strictly a ReiserFS issue (code or whatnot) or is it an issue in how ReiserFS
uses the memory? If it is an issue in how the memory is used, then is it
possible for servers that have a heavy load with lots of dynamic content (and
therefore lots of memory usage) to also still have this issue with 2.2.18
regardless of whether they have ReiserFS or not?
I'll be applying 2.2.18 soon, so the question is sort of moot as I will find
out eventually. Nonetheless, I would appreciate an absolute resolution to
this issue that has been on my mind, not to mention the fact that it would
more than likely give me a break from hearing the pager go off in the
wee-morning hours, eh?
Jim Olsen
Linux Systems Administrator
--
Bus error -- please leave by the rear door.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next reply other threads:[~2001-01-07 11:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-07 11:31 Jim Olsen [this message]
2001-01-07 11:50 ` Which kernel fixes the VM issues? Andre Tomt
2001-01-07 12:06 ` Ville Herva
2001-01-07 12:47 ` Andre Tomt
2001-01-07 12:55 ` Ville Herva
2001-01-07 14:08 ` Alan Cox
2001-01-07 16:55 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01010706312902.10913@jim.cyberjunkees.com \
--to=jim@browsermedia.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.