2.4.20-ck5

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:

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:

XFS must be responsible. I can't test it fully myself but it appears to be related to the latest xfs update I've included in -ck5 which is a snapshot from the sgi website only a week old. Until further notice, use ck4 if you wish to use XFS.

Thanks for the feedback.

Con

Quoted 5 lines · Con Kolivas

XFS must be responsible. I can't test it fully myself but it appears to be related to the latest xfs update I've included in -ck5 which is a snapshot from the sgi website only a week old. Until further notice, use ck4 if you wish to use XFS.

Quoted 3 lines

Thanks for the feedback.

Con

Thanks Con. Now that I think about it, I probably should've cc'd the xfs list. There was some work done on memory leaks in XFS recently - something in here must expose additional leaks. Thanks again,

Quoted 5 lines · Con Kolivas

XFS must be responsible. I can't test it fully myself but it appears to be related to the latest xfs update I've included in -ck5 which is a snapshot from the sgi website only a week old. Until further notice, use ck4 if you wish to use XFS.

Quoted 3 lines

Thanks for the feedback.

Con

Thanks Con. Now that I think about it, I probably should've cc'd the xfs list. There was some work done on memory leaks in XFS recently - something in here must expose additional leaks. Thanks again,

Ok I've posted the old xfs patch (1.2pre5) on my website which is known to work with -ck*. So if you wish to use xfs and ck5 please use the separated out patches.

Con

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,

(quoted diff) +0 -2

-Walt
 
-

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/

I had almost same experience, not using xfs here.

Quoted 1 line · Bob Johnson

I had almost same experience, not using xfs here.

Did you have it patched in?

Con
-
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/

I also have had a problem with ck5. I've been using the ckX kernel for a while now, and they're great kernels. ck4 was absolutely solid. I've been following the interactiveness changes in 2.5, although I don't use it, with some interest, so I was really happy when you announced them in ck5. However, it broke my Evolution. In large folders (such as LKML), the current message jumps around randomly umong the unread messages when I try and select the next unread message. This does not happen with ck4 on an otherwise unchanged system (I use gentoo 1.4). I remember information about 2.5 breaking Evolution, but that was a long time before these interactive fixes. Here are my versions. If there's anything else you want, let me know.