Re: 2.4.20-ck5

Re: 2.4.20-ck5

[Walt H]

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

Re: 2.4.20-ck5

[Con Kolivas]

On Sat, 12 Apr 2003 00:54, Walt H wrote:
> 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).

OOMK not enabled in -ck*

> 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

Re: 2.4.20-ck5

[Walt H]

Con Kolivas wrote:

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

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,

-Walt

Re: 2.4.20-ck5

[Con Kolivas]

On Sat, 12 Apr 2003 01:05, you wrote:
> Con Kolivas wrote:
> > 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
>
> 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,

No problem. I need the feedback. There is no point cc'ing the xfs list because 
my patch is an altered version so I cant be certain that it's the xfs patch 
or my merging responsible unless you try the patch by itself from their 
website. It's up to you if you have the time and inclination to do this.

Con

Re: 2.4.20-ck5

[Con Kolivas]

On Sat, 12 Apr 2003 01:05, Walt H wrote:
> Con Kolivas wrote:
> > 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
>
> 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

Re: 2.4.20-ck5

[Walt H]

Con Kolivas wrote:
> 
> 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
> 

Thanks Con,

I'll give it a go tonight after work.

-Walt

Re: 2.4.20-ck5

[Bob Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had almost same experience,  not using xfs here.

			Bob
On Friday 11 April 2003 09:54 am, Walt H wrote:
> 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
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+lvFHxJgsCy9JAX0RAiOkAJ9DkYNI33rvcMALBe+xlS1x/6OewACeL5Fo
Dn/sIC5+7+iTIAzlsv/9/2M=
=K1L1
-----END PGP SIGNATURE-----

Re: 2.4.20-ck5

[Con Kolivas]

On Sat, 12 Apr 2003 02:45, Bob Johnson wrote:
> I had almost same experience,  not using xfs here.

Did you have it patched in?

Con

Re: 2.4.20-ck5

[Bob Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 I used the full ck5 patch, so it contains xfs.
I just booted ck5 using the rmap15e patch.

			Bob
On Friday 11 April 2003 11:58 am, Con Kolivas wrote:
> On Sat, 12 Apr 2003 02:45, Bob Johnson wrote:
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+lvdyxJgsCy9JAX0RAuZwAKCBXFNmEezfw74DNikxGxnUntCL+gCfclCf
9rW5d3Vu+N8/NrcvOYOmpkY=
=RA78
-----END PGP SIGNATURE-----

Re: 2.4.20-ck5

[Daniel Gryniewicz]

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.

Linux athena.fprintf.net 2.4.20-ck4 #2 Fri Feb 28 17:57:59 EST 2003 i686
AMD Athlon(tm) Processor AuthenticAMD GNU/Linux
 
Gnu C                  3.2.2
Gnu make               3.80
util-linux             2.11y
mount                  2.11y
modutils               2.4.25
e2fsprogs              1.32
reiserfsprogs          3.6.4
pcmcia-cs              3.2.1
Linux C Library        2.3.1
Dynamic linker (ldd)   2.3.1
Procps                 2.0.10
Net-tools              1.60
Kbd                    1.06
Sh-utils               2.0.15
Modules Loaded         sr_mod ide-scsi ide-cd cdrom scsi_mod orinoco_cs
orinoco hermes snd-via82xx snd-ac97-codec snd-pcm snd-timer
snd-mpu401-uart snd-rawmidi snd-seq-device snd soundcore usbcore vfat
fat ds i82365 pcmcia_core rtc

-- 
Daniel Gryniewicz <dang@fprintf.net>

Re: 2.4.20-ck5

[Con Kolivas]

On Tue, 15 Apr 2003 11:41, Daniel Gryniewicz wrote:
> 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.

Yes sorry it's ck5's fault, it's b0rken. Use ck6 which is on the website now 
called ck6pre_2416030413_2.4.20.patch.bz2 It doesn't have the mem leak in ck5 
and has the interactivity patch removed. Ignore the pre name it's going to be 
renamed when I update my website et al. This should be as stable as ck4.

Con

2.4.20-ck5

[Con Kolivas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've posted an update to my patchset:

http://kernel.kolivas.org

O(1) scheduler
Interactivity backport
Preempt
Low Latency
AA VM
Read Latency2
Supermount
XFS 1.2
ACPI
CD/DVD Packet Writing
Variable HZ
Scheduler Tunables
Desktop Tuning
+/- Rmap15e

Significant updates:
The interactivity changes to the O(1) scheduler by Mingo have been 
incorporated.
Supermount has had a minor touch up to remove annoying warnings on shutdown.
XFS has been updated to the latest snapshot.
Hz may be set at config time again
Scheduler tunables has been backported from 2.5
Rmap has been updated to 15e

It became clear that even with the interactivity changes audio skipping could 
occur so I've added some more desktop tuning to this version far less drastic 
than the previous kernels. The desktop tuning patch just changes a few of the 
default settings and these are all able to be modified at config or after 
boot if so desired. The options chosen were:

Hz set to 500
Min timeslice set to 2ms
Max Timeslice set to 40ms

A FAQ on NOT renicing X with this kernel has been added to my homepage.

Please feel free to send me comments, queries, suggestions, bug reports, 
patches etc.

Enjoy!
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+lDNAF6dfvkL3i1gRAqVSAJ4v6YMFE4OH0hN/EeOM5xssu7JrqwCglp3t
DXDZ8zNH90jxivl7I4nKee8=
=TZkg
-----END PGP SIGNATURE-----