Only in 2.4.13pre2aa1: 00_lvm-1.0.1-rc4-1.bz2
Only in 2.4.13pre3aa1: 00_lvm-1.0.1-rc4-2.bz2
Rediffed merging the unsigned long change in the blkdev size ioctl.
Only in 2.4.13pre2aa1: 00_vm-3.1
Only in 2.4.13pre3aa1: 00_vm-3.2
Further vm minor updates. In particular make sure not to overstimate
the amount of buffers available during balance_dirty(), by using the
exact per-classzone active/inactive info.
Only in 2.4.13pre2aa1: 50_uml-patch-2.4.12-1-1.bz2
Only in 2.4.13pre3aa1: 50_uml-patch-2.4.12-3-1.bz2
Latest update from Jeff.
Only in 2.4.13pre2aa1: 60_tux-2.4.10-ac10-F5.bz2
Only in 2.4.13pre3aa1: 60_tux-2.4.10-ac12-H1.bz2
Latest update from Ingo.
Andrea
On Tuesday 16 October 2001 11:07, Andrea Arcangeli wrote:
> Only in 2.4.13pre2aa1: 00_lvm-1.0.1-rc4-1.bz2
> Only in 2.4.13pre3aa1: 00_lvm-1.0.1-rc4-2.bz2
>
> Rediffed merging the unsigned long change in the blkdev size ioctl.
>
> Only in 2.4.13pre2aa1: 00_vm-3.1
> Only in 2.4.13pre3aa1: 00_vm-3.2
>
> Further vm minor updates. In particular make sure not to overstimate
> the amount of buffers available during balance_dirty(), by using the
> exact per-classzone active/inactive info.
>
> Only in 2.4.13pre2aa1: 50_uml-patch-2.4.12-1-1.bz2
> Only in 2.4.13pre3aa1: 50_uml-patch-2.4.12-3-1.bz2
>
> Latest update from Jeff.
>
> Only in 2.4.13pre2aa1: 60_tux-2.4.10-ac10-F5.bz2
> Only in 2.4.13pre3aa1: 60_tux-2.4.10-ac12-H1.bz2
>
> Latest update from Ingo.
>
> Andrea
I was expecting a more serious bug-fix. I recently upgraded my kernel from
2.4.11pre1 to 2.4.13-pre2aa1. Now anacron "kill"s the machine every morning
by starting updatedb. Basicly everything swaps out. If I don't touch the
mouse for 3 seconds, it will take 15 seconds to respond next time I touch it.
Switching between desktops in KDE, takes from 3 to 10 minutes, and updatedb
never seems to complete, I have had to kill it manually every time so far. I
had similar problems every morning with 2.4.9 although not as bad, but I
havent seen them before in 2.4.10 and later.
The problem is easily replicable, I just need to run updatedb. Would you like
some statistics and which?
regards
`Allan
On Tue, 16 Oct 2001 14:30:43 +0200 Allan Sandfeld <[email protected]> wrote:
> I was expecting a more serious bug-fix. I recently upgraded my kernel from
> 2.4.11pre1 to 2.4.13-pre2aa1. Now anacron "kill"s the machine every morning
> by starting updatedb. Basicly everything swaps out. If I don't touch the
> mouse for 3 seconds, it will take 15 seconds to respond next time I touch it.
> Switching between desktops in KDE, takes from 3 to 10 minutes, and updatedb
> never seems to complete, I have had to kill it manually every time so far. I
> had similar problems every morning with 2.4.9 although not as bad, but I
> havent seen them before in 2.4.10 and later.
> The problem is easily replicable, I just need to run updatedb. Would you like
> some statistics and which?
That would be really interesting. If you want to have a look:
admin:/etc # cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 922664960 882900992 39763968 0 104587264 214876160
Swap: 271392768 0 271392768
MemTotal: 901040 kB
MemFree: 38832 kB
MemShared: 0 kB
Buffers: 102136 kB
Cached: 209840 kB
SwapCached: 0 kB
Active: 40252 kB
Inactive: 271724 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 901040 kB
LowFree: 38832 kB
SwapTotal: 265032 kB
SwapFree: 265032 kB
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda3 6297280 5941616 355664 95% /
/dev/sda2 31111 25873 3632 88% /boot
/dev/hda1 20043416 19405616 637800 97% /p3
/dev/sda4 29245432 27529888 1715544 95% /p2
shmfs 450520 0 450520 0% /dev/shm
admin:/ # time updatedb --localpaths="/ /p2 /p3"
real 0m19.197s
user 0m15.440s
sys 0m5.260s
admin:/etc # ls -l /var/lib/locatedb
-rw-r--r-- 1 root root 5321293 Oct 16 15:13 /var/lib/locatedb
admin:/etc # uname -r
2.4.13-pre2
3:14pm up 2 days, 18:15, 24 users, load average: 1.16, 1.10, 1.04
119 processes: 117 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states: 54.5% user, 2.4% system, 53.0% nice, 42.4% idle
CPU1 states: 45.0% user, 1.1% system, 45.1% nice, 53.1% idle
Mem: 901040K av, 847480K used, 53560K free, 0K shrd, 90544K buff
Swap: 265032K av, 0K used, 265032K free 206296K cached
On my system I cannot see anything the like. Look at the execution time.
Ok, I must admit: I do not use brain-dead K stuff (warning: this is a very
personal opinion, don't flame me here :-).
What does your setup look like? Have you ever tested without K?
Regards,
Stephan
On Tuesday 16 October 2001 15:21, you wrote:
>
> On my system I cannot see anything the like. Look at the execution time.
> Ok, I must admit: I do not use brain-dead K stuff (warning: this is a very
> personal opinion, don't flame me here :-).
>
> What does your setup look like? Have you ever tested without K?
>
No, I havent tried it without K. The system is quite responsive if I only run
updatedb, and swap around in either text-linux or a simple X setup. When
looking closer at the problem, it is the combination of running kmail with
HUGE folders (think linux-kernel archive), apt-get and anacron that thrashes
the system. All of these have a "relative" low impact when running alone or
two and two.
It might be "what you expect" abusing the system like that. But as I said, it
is not a problem in 2.4.11-pre1 and 2.4.12-ac3.
Princess:/home# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 196304896 192466944 3837952 0 1327104 33628160
Swap: 255426560 64491520 190935040
MemTotal: 191704 kB
MemFree: 3748 kB
MemShared: 0 kB
Buffers: 1296 kB
Cached: 28196 kB
SwapCached: 4644 kB
Active: 23344 kB
Inactive: 10792 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 191704 kB
LowFree: 3748 kB
SwapTotal: 249440 kB
SwapFree: 186460 kB
Princess:/proc# uname -r
2.4.13-pre2
Princess:/proc# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 18975356 9843804 8167652 55% /
/dev/hda1 7318 7241 0 100% /boot
15:52:56 up 1:03, 2 users, load average: 3.44, 3.95, 3.16
90 processes: 86 sleeping, 2 running, 2 zombie, 0 stopped
CPU states: 23.7% user, 3.4% system, 0.0% nice, 73.0% idle
Mem: 191704K total, 188024K used, 3680K free, 2652K buffers
Swap: 249440K total, 61744K used, 187696K free, 21268K cached
Does all this help you?
Notice this is not worst case, just what I could reproduce by starting
updatedb and checksecurity while answering your mail. Switchtime from desktop
to desktop is 1 minute.
`Allan
And here's the last one:
Princess:/# time updatedb
updatedb 46,95s user 8,56s system 3% cpu 24:20,55 total
On Tue, 16 Oct 2001 15:55:27 +0200 Allan Sandfeld <[email protected]> wrote:
> On Tuesday 16 October 2001 15:21, you wrote:
> >
> > On my system I cannot see anything the like. Look at the execution time.
> > Ok, I must admit: I do not use brain-dead K stuff (warning: this is a very
> > personal opinion, don't flame me here :-).
> >
> > What does your setup look like? Have you ever tested without K?
> >
> No, I havent tried it without K. The system is quite responsive if I only run
> updatedb, and swap around in either text-linux or a simple X setup. When
> looking closer at the problem, it is the combination of running kmail with
> HUGE folders (think linux-kernel archive), apt-get and anacron that thrashes
> the system. All of these have a "relative" low impact when running alone or
> two and two.
> It might be "what you expect" abusing the system like that. But as I said, it
> is not a problem in 2.4.11-pre1 and 2.4.12-ac3.
>
> Princess:/home# cat /proc/meminfo
> total: used: free: shared: buffers: cached:
> Mem: 196304896 192466944 3837952 0 1327104 33628160
> Swap: 255426560 64491520 190935040
> MemTotal: 191704 kB
> MemFree: 3748 kB
> MemShared: 0 kB
> Buffers: 1296 kB
> Cached: 28196 kB
> SwapCached: 4644 kB
> Active: 23344 kB
> Inactive: 10792 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 191704 kB
> LowFree: 3748 kB
> SwapTotal: 249440 kB
> SwapFree: 186460 kB
>
> Princess:/proc# uname -r
> 2.4.13-pre2
>
> Princess:/proc# df
> Filesystem 1k-blocks Used Available Use% Mounted on
> /dev/hda3 18975356 9843804 8167652 55% /
> /dev/hda1 7318 7241 0 100% /boot
>
> 15:52:56 up 1:03, 2 users, load average: 3.44, 3.95, 3.16
> 90 processes: 86 sleeping, 2 running, 2 zombie, 0 stopped
> CPU states: 23.7% user, 3.4% system, 0.0% nice, 73.0% idle
> Mem: 191704K total, 188024K used, 3680K free, 2652K buffers
> Swap: 249440K total, 61744K used, 187696K free, 21268K cached
>
>
> Does all this help you?
Hm, from looking at the presented numbers I tend to believe that you are
driving this system up to the limits. Very possible that ac kernels deal a bit
better with the situation because of neat swap-management. But very much of
your mem is really used by appilcations and very few (in comparison) is used by
page cache, so there is not really much room to play with. If I were to give
advice, I'd either
a) buy mem (something like additional 256 MB)
or
b) throw away K, and replace by more resource-conscious stuff like wm, or/and
an acceptable mail-client like sylpheed.
Both would do quantum-leaps in your configuration, compared to very small
playground left for vm treatment. Whatever is swapped could be the wrong thing,
depending on your further actions.
Try it and compare the time and memory consumption for:
a) Startup
b) Exit
c) Starting your mail-client
d) updatedb
with K and with wm (just to mention a nice example)
> Notice this is not worst case, just what I could reproduce by starting
> updatedb and checksecurity while answering your mail. Switchtime from desktop
> to desktop is 1 minute.
Sure. I would say it swaps the hell out. K tends to be the wrong choice in a
less-than-completely-oversized system. As I said, Riks vm may help you _this
time_. But possibly only up to the next K release, where everything is again
slower, bigger and more unstable. Solve the problem, do not maneuver around it.
Just my personal opinion.
Regards,
Stephan
On Tuesday 16 October 2001 20:38, Stephan von Krawczynski wrote:
>
> Hm, from looking at the presented numbers I tend to believe that you are
> driving this system up to the limits. Very possible that ac kernels deal a
> bit better with the situation because of neat swap-management. But very
> much of your mem is really used by appilcations and very few (in
> comparison) is used by page cache, so there is not really much room to play
> with. If I were to give advice, I'd either
> a) buy mem (something like additional 256 MB)
> or
> b) throw away K, and replace by more resource-conscious stuff like wm,
> or/and an acceptable mail-client like sylpheed.
> Both would do quantum-leaps in your configuration, compared to very small
> playground left for vm treatment. Whatever is swapped could be the wrong
> thing, depending on your further actions.
> Try it and compare the time and memory consumption for:
> a) Startup
> b) Exit
> c) Starting your mail-client
> d) updatedb
> with K and with wm (just to mention a nice example)
e) Just hope the bug is already fixed
On a suggestion from Luigi Genoni I tried 2.4.13-pre3aa1. The problem IS
infact fixed. From a subjective point of view I would again claim the Andrea
VM leaves the system much more responsive when updatedb is running than the
VM in 2.4.12-ac3.
Nice!! :)
Regards.
`Allan