Subject: Re: new memory allocation scheme and disk access
To: Lennart Augustsson <lennart@augustsson.net>
From: Bang Jun-Young <junyoung@NetBSD.org>
List: current-users
Date: 01/03/2004 02:16:01
On Fri, Jan 02, 2004 at 06:01:28PM +0100, Lennart Augustsson wrote:
> Yes, I just experienced this as well. And if you include doing
> `make depend' it gets even worse, I think. This code cannot
> stay as it is, I mean a 3-fold slowdown is pretty awful.
>
> -- Lennart
I'm seeing the same problem, too. The kernel is taking up so much
memory and swap is running short, neither of which has never seen on my
512M machine. Current top(1) output is as follows:
load averages: 3.05, 3.25, 3.24 02:05:49
69 processes: 68 sleeping, 1 on processor
Memory: 183M Act, 103M Inact, 1056K Wired, 45M Exec, 172M File, 22M Free
Swap: 129M Total, 108M Used, 21M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
15314 junyoung 2 0 7268K 13M select 3:11 0.63% 0.63% kdeinit
12481 junyoung 2 0 23M 30M select 9:22 0.15% 0.15% XFree86
29199 junyoung 10 0 728K 1328K wait 0:00 0.44% 0.10% make
9 root -18 0 0K 180M reaper 1:57 0.05% 0.05% [reaper]
26254 junyoung 2 0 30M 35M select 4:36 0.00% 0.00% kdeinit
19251 junyoung 2 0 3120K 11M select 4:33 0.00% 0.00% kdeinit
28045 junyoung 2 0 30M 38M select 1:48 0.00% 0.00% kdeinit
1059 junyoung 2 0 5332K 14M select 1:35 0.00% 0.00% kdeinit
635 junyoung 2 0 4912K 12M select 1:26 0.00% 0.00% kdeinit
10 root 18 0 0K 180M syncer 1:10 0.00% 0.00% [ioflush]
542 junyoung 2 0 4780K 11M select 0:52 0.00% 0.00% kdeinit
23019 junyoung 2 0 5308K 14M select 0:40 0.00% 0.00% kdeinit
476 junyoung 2 0 12M 14M select 0:29 0.00% 0.00% kget
6971 junyoung 2 0 5608K 6704K select 0:26 0.00% 0.00% kdeinit
4512 junyoung 2 0 11M 2240K select 0:19 0.00% 0.00% kdeinit
20822 junyoung 2 0 2728K 4928K select 0:14 0.00% 0.00% artsd
6575 junyoung 2 0 6320K 6468K select 0:11 0.00% 0.00% kdeinit
13975 junyoung 2 0 5608K 3752K poll 0:10 0.00% 0.00% nabi
And I noticed time took on building XFree86-current got tremendously
longer (2 or 3 fold) with the new bufcache scheme.
Jun-Young
--
Bang Jun-Young <junyoung@NetBSD.org>