Hello all!
I'm very glad of VM in kernel 2.4.13. It was the first time today, that
my backup run without any problem and without massive caching on the
backup-Server (only about 10MB during KDE2-session with konqueror,
knode, ...) . Working parallel with other applications has acceptable
performance.
Comparison with 2.4.13-ac4:
Nearly the same programs running in background, the backup break down
after about 60s of getting datas via ethernet. At this point, the swap
has been grown over 56Mb!! Normally (= if the backup runs to the end at
the second or third try), 300MB swap weren't enough. Working with other
applications is impossible or painful.
I do my backups of the whole harddisks (all in one over 20 GB) with
rsync (of remote machines too) to another HD on the desktop, which is
only used for these backups.
My system:
backup-server (also desktop): 512 MB RAM, usually 256 MB cache, Athlon
800 with 2 UDMA4-disks (20 and 45GB).
lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [PCI-PCI Bridge]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
[Apollo Super AC97/Audio] (rev 20)
00:08.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900
10/100 Ethernet (rev 02)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
(rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF
Unfortunately, there is one great (old) problem with any
2.4.x-vanilla-kernel, which isn't fixed until today and which prevents
me of using the vanilla kernel:
Usually after some restarts of the X-sserver (4.x.y), my screen (not the
monitor itself; no sleep-modus is shown) is beginning to go off and on
again (when the mouse is moved) within seconds. You can't get rid of it
by restarting X - you have to reboot the machine.
This problem doesn't occur with ac-kernels.
I'm using DRI - but without DRI, the problem doesn't disappear :-(. I'm
using no energy-safing modes - and nothing is configured or compiled
thereto.
Regards,
Andreas Hartmann
I'm now testing 2.4.14-pre6, and in at the first time the kswapd is very
calm, the performance is very better, my DB ENGINE now run with 4 cpu, 2GB
shared memory buffer pool, on a 4 cpu machine and 4GB RAM using the total
performance of the machine.
In 2.4.13-ac3 read data from my STORAGE the maximum I/O performance is
40MBytes/s, but in 2.4.14-pre6 this value grows to 60MBytes/s.
In 2.4.13-ac3 or 2.4.10-ac7 after hours of uptime the machine lost
performance, he enters in "degraded mode", my process run very slow, I need
to do a reboot every morning to the performance return to "normal". In
2.4.14-pre6 this no happens, at this moment, the machine is 1 day uptime, and
I run big select on database and run very faster, no degradation on
performance after 1 day of uptime.
The swap area remains in 0 KB off use.
In the olds versions when I/O grows, the kswapd grows together using 100% of
cpu, this not happens in 2.4.14-pre6.
Yestarday I run a total reorg in the database for tests and runs OK, in
2.4.13 after a while the VM locks.
At this time everything is OK
Congratulations for all
Andr?
Em Qui 01 Nov 2001 10:28, Andreas Hartmann escreveu:
> Hello all!
>
> I'm very glad of VM in kernel 2.4.13. It was the first time today, that
> my backup run without any problem and without massive caching on the
> backup-Server (only about 10MB during KDE2-session with konqueror,
> knode, ...) . Working parallel with other applications has acceptable
> performance.
>
> Comparison with 2.4.13-ac4:
> Nearly the same programs running in background, the backup break down
> after about 60s of getting datas via ethernet. At this point, the swap
> has been grown over 56Mb!! Normally (= if the backup runs to the end at
> the second or third try), 300MB swap weren't enough. Working with other
> applications is impossible or painful.
>
>
> I do my backups of the whole harddisks (all in one over 20 GB) with
> rsync (of remote machines too) to another HD on the desktop, which is
> only used for these backups.
>
>
> My system:
> backup-server (also desktop): 512 MB RAM, usually 256 MB cache, Athlon
> 800 with 2 UDMA4-disks (20 and 45GB).
>
> lspci
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [PCI-PCI Bridge]
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
> 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
> 10) 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
> (rev 30)
> 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
> [Apollo Super AC97/Audio] (rev 20)
> 00:08.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900
> 10/100 Ethernet (rev 02)
> 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
> (rev 10)
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF
>
>
> Unfortunately, there is one great (old) problem with any
> 2.4.x-vanilla-kernel, which isn't fixed until today and which prevents
> me of using the vanilla kernel:
> Usually after some restarts of the X-sserver (4.x.y), my screen (not the
> monitor itself; no sleep-modus is shown) is beginning to go off and on
> again (when the mouse is moved) within seconds. You can't get rid of it
> by restarting X - you have to reboot the machine.
> This problem doesn't occur with ac-kernels.
> I'm using DRI - but without DRI, the problem doesn't disappear :-(. I'm
> using no energy-safing modes - and nothing is configured or compiled
> thereto.
>
>
> Regards,
> Andreas Hartmann
>
> -
> 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/