All of lore.kernel.org
 help / color / mirror / Atom feed
From: Walt H <waltabbyh@comcast.net>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: kernel@kolivas.org
Subject: Re: 2.4.20-ck5
Date: Fri, 11 Apr 2003 07:54:09 -0700	[thread overview]
Message-ID: <3E96D711.70404@comcast.net> (raw)

Hello,

I've compiled a new kernel using the ck5 patchset you made, but have had
some problems. It seems that with my configuration, I expose a memory
leak somewhere. After the system has been up for a while, or if I try to
compile anything non-trivial (kde-libs for example), The system will use
up all available memory and further memory alloc's fail. Swap is hardly
being used in this case. My syslog file does report:


Apr 10 19:06:19 waltsathlon kernel: __alloc_pages: 1-order allocation
failed (gfp=0x1f0/0)
Apr 10 19:06:19 waltsathlon kernel: __alloc_pages: 0-order allocation
failed (gfp=0xf0/0)
Apr 10 19:06:19 waltsathlon kernel: __alloc_pages: 1-order allocation
failed (gfp=0x1f0/0)

Typically, apps fail although the OOM killer isn't triggered (not sure
if it's enabled in ck5).

I'm wondering if there's a strange interaction with XFS? I also use the
Nvidia driver, however, I also tested without loading it and receive the
same results. My XFS thought is due to the strange behaviour of the
filesystem with this patchset. When I tried compiling kdelibs, the
system chugged along until memory was used (15-20 mins) and then the
compile could no longer proceed. After seeing this and issuing a 'sync',
the drives thrashed for approx. 30-45 seconds as if flushing unwritten
data. It's as if writes are being stored indefinitely? Reverting back to
ck4 and all is well. System info below:

Chaintech 7KDD 760MPX MB
2 x AMD 2400MP
1 GB ECC Ram
2-2 disk striped arrays - 1 software MD, 1 Promise Fasttrak
XFS filesystem on all mount points except boot
Compiled with GCC-3.2.2
glibc-2.3.1

Anything else you need? Please CC as I'm not subscribed. Thanks,

-Walt


             reply	other threads:[~2003-04-11 14:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-11 14:54 Walt H [this message]
2003-04-11 15:01 ` 2.4.20-ck5 Con Kolivas
2003-04-11 15:05   ` 2.4.20-ck5 Walt H
2003-04-11 15:11     ` 2.4.20-ck5 Con Kolivas
2003-04-11 15:34     ` 2.4.20-ck5 Con Kolivas
2003-04-11 15:58       ` 2.4.20-ck5 Walt H
2003-04-11 16:45 ` 2.4.20-ck5 Bob Johnson
2003-04-11 16:58   ` 2.4.20-ck5 Con Kolivas
2003-04-11 17:12     ` 2.4.20-ck5 Bob Johnson
2003-04-15  1:41 ` 2.4.20-ck5 Daniel Gryniewicz
2003-04-15  2:06   ` 2.4.20-ck5 Con Kolivas
  -- strict thread matches above, loose matches on Subject: below --
2003-04-09 14:50 2.4.20-ck5 Con Kolivas

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=3E96D711.70404@comcast.net \
    --to=waltabbyh@comcast.net \
    --cc=kernel@kolivas.org \
    --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.