Skip to contentSkip to conversation

2.6.8.1-ck4

DISCUSSION Con Kolivas 6 participants 16 messages Aug 22, 2004 – Aug 26, 2004

Subsystems (7)
lore
Share & tools
lore
#0 lore raw

Patchset update. These are patches designed to improve system responsiveness with specific emphasis on the desktop, but configurable to any workload.

The short time between ck3 and ck4 is for two reasons. First Ingo discovered a nasty bug affecting X performance and I believe I made a reasonable breakthrough on the never ending desktop vm swappiness saga.

Web site with faq:
http://kernel.kolivas.org
Patches (with split-out also):
http://ck.kolivas.org/patches/2.6/2.6.8.1/2.6.8.1-ck4/

Added since 2.6.8.1-ck3:
+mapped_watermark.diff

This readjusts the way memory is evicted by lightly removing cached ram once the ram is more than 2/3 full, if less than the "mapped watermark" percent of ram is mapped ram (ie applications). The normal system is to aggresively start scanning ram once it is completely full. The benefits of this are:
1. Allocating memory while ram is being lightly scanned is faster and cheaper than when it is being heavily scanned.
2. There is usually some free ram which tends to speed up application startup times.
3. Swapping is an unusual event instead of a common one if you have enough ram for your workload.
4. It is rare for your applications to be swapped out by file cache pressure.
Disadvantage: Less file cache - but can be offset with the tunable

The mapped watermark is configurable so a server for example might be happy to have a lower mapped percentage. The default is 66 and a server might like 33 (0 is also fine)

echo 33 > /proc/sys/vm/mapped

This patch removes the swappiness knob entirely and deprecates all my previous vm hacks (autoregulated swappiness, hard swappiness, kiflush).

+ioport-latency-fix-2.6.8.1.patch
A nasty bug Ingo tracked down that caused high latencies and cache trashing with X.

Changed:
~Staircase8.0
Backed out a tweak designed to improve behaviour under filesystem load - I am avoiding all "tweaks" in the design, and it's effectiveness was questionable. Added a tiny check to recalc_task_prio which should make it safe when the Hz value is set below 500.

~1g_lowmem_i386
Made the 1Gb of lowmem configurable if highmem is disabled.

Removed:
-hard_swappiness1.diff
-kiflush3.diff
Deprected in favour of mapped_watermark

Full patchlist:
from_2.6.8.1_to_staircase8.0.bz2
schedrange.diff
schedbatch2.4.diff
schediso2.5.diff
sched-adjust-p4gain
mapped_watermark.diff
defaultcfq.diff
config_hz.diff
1g_lowmem_i386.diff
akpm-latency-fix.patch
9000-SuSE-117-writeback-lat.patch
cddvd-cmdfilter-drop.patch
cool-spinlocks-i386.diff
bio_uncopy_user-mem-leak.patch
bio_uncopy_user2.diff
ioport-latency-fix-2.6.8.1.patch
supermount-ng204.diff.bz2
fbsplash-0.9-r5-2.6.8-rc3.patch.bz2
make-tree_lock-an-rwlock.patch.bz2
invalidate_inodes-speedup.patch
2.6.8.1-mm2-reiser4.diff.bz2
2.6.8.1-ck4-version.diff

Cheers,
Con

#1 lore raw
Quoted 10 lines · Con Kolivas

Patchset update. These are patches designed to improve system responsiveness with specific emphasis on the desktop, but configurable to any workload.

The short time between ck3 and ck4 is for two reasons. First Ingo discovered a nasty bug affecting X performance and I believe I made a reasonable breakthrough on the never ending desktop vm swappiness saga.

Web site with faq:
http://kernel.kolivas.org
Patches (with split-out also):
http://ck.kolivas.org/patches/2.6/2.6.8.1/2.6.8.1-ck4/

Quoted 4 lines

Added since 2.6.8.1-ck3:
+mapped_watermark.diff

This readjusts the way memory is evicted by lightly

can you specify lightly with another sentence or two of detail? Thanks,

Hans

Quoted 61 lines

removing cached ram once the ram is more than 2/3 full, if less than the "mapped watermark" percent of ram is mapped ram (ie applications). The normal system is to aggresively start scanning ram once it is completely full. The benefits of this are:
1. Allocating memory while ram is being lightly scanned is faster and cheaper than when it is being heavily scanned.
2. There is usually some free ram which tends to speed up application startup times.
3. Swapping is an unusual event instead of a common one if you have enough ram for your workload.
4. It is rare for your applications to be swapped out by file cache pressure.
Disadvantage: Less file cache - but can be offset with the tunable

The mapped watermark is configurable so a server for example might be happy to have a lower mapped percentage. The default is 66 and a server might like 33 (0 is also fine)

echo 33 > /proc/sys/vm/mapped

This patch removes the swappiness knob entirely and deprecates all my previous vm hacks (autoregulated swappiness, hard swappiness, kiflush).

+ioport-latency-fix-2.6.8.1.patch
A nasty bug Ingo tracked down that caused high latencies and cache trashing with X.

Changed:
~Staircase8.0
Backed out a tweak designed to improve behaviour under filesystem load
- I am avoiding all "tweaks" in the design, and it's effectiveness was
questionable.
Added a tiny check to recalc_task_prio which should make it safe when the Hz value is set below 500.

~1g_lowmem_i386
Made the 1Gb of lowmem configurable if highmem is disabled.

Removed:

(quoted diff) +0 -2
-hard_swappiness1.diff
-kiflush3.diff

Deprected in favour of mapped_watermark

Full patchlist:
from_2.6.8.1_to_staircase8.0.bz2
schedrange.diff
schedbatch2.4.diff
schediso2.5.diff
sched-adjust-p4gain
mapped_watermark.diff
defaultcfq.diff
config_hz.diff
1g_lowmem_i386.diff
akpm-latency-fix.patch
9000-SuSE-117-writeback-lat.patch
cddvd-cmdfilter-drop.patch
cool-spinlocks-i386.diff
bio_uncopy_user-mem-leak.patch
bio_uncopy_user2.diff
ioport-latency-fix-2.6.8.1.patch
supermount-ng204.diff.bz2
fbsplash-0.9-r5-2.6.8-rc3.patch.bz2
make-tree_lock-an-rwlock.patch.bz2
invalidate_inodes-speedup.patch
2.6.8.1-mm2-reiser4.diff.bz2
2.6.8.1-ck4-version.diff

Cheers,
Con

#2 lore raw
Quoted 10 lines · Hans Reiser
Quoted 4 lines · Con Kolivas

Added since 2.6.8.1-ck3:
+mapped_watermark.diff

This readjusts the way memory is evicted by lightly

can you specify lightly with another sentence or two of detail? Thanks,

Hans

Sure.

This adds another watermark to the logic used to wake up kswapd. kswapd is woken once there is less than 1/3 of physical ram free. The current watermark is used by kswapd to evict nr_pages to make room for whatever is trying to get ram. It does this by increasing the proportion of ram scanned each time it fails to allocate enough ram and will also start evicting mapped pages. With mapped_watermark, once awoken it will only ever scan at the lowest priority (DEF_PRIORITY) and never evict mapped pages. It only starts scanning if less than the tunable (mapped) percent of the in-use physical ram is mapped. If it does not manage to evict nr_pages it simply returns quietly allowing the physical ram to be consumed. As it is in the mainline vm, the watermark is always hit anyway, which means we're always scanning at potentially higher priority (and repeatedly) and always considering mapped pages.

The patch in it's entirety is small enough to review attached below.

Cheers,
Con

 include/linux/mmzone.h |    3 +
 include/linux/swap.h   |    2 -
 include/linux/sysctl.h |    2 -
 kernel/sysctl.c        |    8 ++--
 mm/page_alloc.c        |    4 ++
 mm/vmscan.c            |   83 
++++++++++++++++++-------------------------------
 6 files changed, 44 insertions(+), 58 deletions(-)
include/linux/mmzone.h +2 -1
Index: linux-2.6.8.1-ck/include/linux/mmzone.h
===================================================================
@@ -125,7 +125,7 @@ struct zone {
 	 */
 	spinlock_t		lock;
 	unsigned long		free_pages;
-	unsigned long		pages_min, pages_low, pages_high;
+	unsigned long		pages_min, pages_low, pages_high, pages_unmapped;
 	/*
 	 * protection[] is a pre-calculated number of extra pages that must be
 	 * available in a zone in order for __alloc_pages() to allocate memory
@@ -276,6 +276,7 @@ typedef struct pglist_data {
 	struct pglist_data *pgdat_next;
 	wait_queue_head_t       kswapd_wait;
 	struct task_struct *kswapd;
+	int maplimit;
 } pg_data_t;
 
 #define node_present_pages(nid)	(NODE_DATA(nid)->node_present_pages)
include/linux/swap.h +1 -1
Index: linux-2.6.8.1-ck/include/linux/swap.h
===================================================================
@@ -174,7 +174,7 @@ extern void swap_setup(void);
 /* linux/mm/vmscan.c */
 extern int try_to_free_pages(struct zone **, unsigned int, unsigned int);
 extern int shrink_all_memory(int);
-extern int vm_swappiness;
+extern int vm_mapped;
 
 #ifdef CONFIG_MMU
 /* linux/mm/shmem.c */
include/linux/sysctl.h +1 -1
Index: linux-2.6.8.1-ck/include/linux/sysctl.h
===================================================================
@@ -159,7 +159,7 @@ enum
 	VM_OVERCOMMIT_RATIO=16, /* percent of RAM to allow overcommit in */
 	VM_PAGEBUF=17,		/* struct: Control pagebuf parameters */
 	VM_HUGETLB_PAGES=18,	/* int: Number of available Huge Pages */
-	VM_SWAPPINESS=19,	/* Tendency to steal mapped memory */
+	VM_MAPPED=19,		/* percent mapped min while evicting cache */
 	VM_LOWER_ZONE_PROTECTION=20,/* Amount of protection of lower zones */
 	VM_MIN_FREE_KBYTES=21,	/* Minimum free kilobytes to maintain */
 	VM_MAX_MAP_COUNT=22,	/* int: Maximum number of mmaps/address-space */
kernel/sysctl.c +4 -4
Index: linux-2.6.8.1-ck/kernel/sysctl.c
===================================================================
@@ -717,10 +717,10 @@ static ctl_table vm_table[] = {
 		.proc_handler	= &proc_dointvec,
 	},
 	{
-		.ctl_name	= VM_SWAPPINESS,
-		.procname	= "swappiness",
-		.data		= &vm_swappiness,
-		.maxlen		= sizeof(vm_swappiness),
+		.ctl_name	= VM_MAPPED,
+		.procname	= "mapped",
+		.data		= &vm_mapped,
+		.maxlen		= sizeof(vm_mapped),
 		.mode		= 0644,
 		.proc_handler	= &proc_dointvec_minmax,
 		.strategy	= &sysctl_intvec,
mm/page_alloc.c +4 -0
Index: linux-2.6.8.1-ck/mm/page_alloc.c
===================================================================
@@ -628,6 +628,9 @@ __alloc_pages(unsigned int gfp_mask, uns
 		 */
 		if (rt_task(p))
 			min -= z->pages_low >> 1;
+		else
+			if (wait && z->free_pages < z->pages_unmapped)
+				wakeup_kswapd(z);
 
 		if (z->free_pages >= min ||
 				(!wait && z->free_pages >= z->pages_high)) {
@@ -1905,6 +1908,7 @@ static void setup_per_zone_pages_min(voi
 
 		zone->pages_low = zone->pages_min * 2;
 		zone->pages_high = zone->pages_min * 3;
+		zone->pages_unmapped = zone->present_pages / 3;
 		spin_unlock_irqrestore(&zone->lru_lock, flags);
 	}
 }
mm/vmscan.c +32 -51

173 lines not on this page · raw message

#3 lore raw
In reply to Con Kolivas

I don't know what or why, but I am experiancing a nightmare with interactivity and heavy nfs use. I am using Gentoo, and I have my portage tree exported from a central server. Trying to do an emerge update world is taking forever.

During the time it is scanning the portage tree it takes 2 - 3 minutes to load Firefox. It also took almost 5 minuts to load GAIM. Once GAIM loaded, none of the screens would paint. I halted the emerge and instantly Gaim painted and all the web pages I was waiting for in firefox finished. So I unleashed emerge again, and tried to load more local-only apps. Same problem. Horrible delays. Halt emerge, and boom, everything snappy and fast.

So, as long as I don't use NFS, this is spectacular, but NFS access is murdering me.

In any case, I would take from recommendations. For testing, etc. I am on the list, but if there is testing, please CC my address.

CPU: Pentium 4 - 1.7Ghz.

memory - [swap usage is already much improved]:
total used free shared buffers cached

Mem:        775200     499796     275404          0       5200     126816
-/+ buffers/cache:     367780     407420
Swap:       799992          0     799992

Root:
Filesystem Size Used Avail Use% Mounted on
/dev/hda2 39G 26G 13G 67% /

#4 lore raw

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

Joshua Schmidlkofer wrote:

| I don't know what or why, but I am experiancing a nightmare with
| interactivity and heavy nfs use.   I am using Gentoo, and I have my
| portage tree exported from a central server.   Trying to do an emerge
| update world is taking forever.

[snip]

Yup I think I have a regression here, as well. I remember an older version of ck exhibited this, but the last one for 2.6.7 did work well (I think even the one for 2.8.6-rc4 was ok), IIRC. In my case, when doing a (niced) compile in background, some windows react very slow, ie Mozilla Thunderbird takes ages to switch trough mails or cliking on an icon in kde to load up konsole takes about 10seconds or more (shoud come up <1sec normally).

Using 2.8.6.1-ck4

HTH,

Prakash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBKicfxU2n/+9+t5gRAqSlAKDrX1TZpPH8Pf+G/NjO6vnEGUwsVACfaKAA WQcbUxP37FR7ZOf26JZhWGs=
=m3OJ
-----END PGP SIGNATURE-----

#5 lore raw
Quoted 8 lines

Yup I think I have a regression here, as well. I remember an older version of ck exhibited this, but the last one for 2.6.7 did work well (I think even the one for 2.8.6-rc4 was ok), IIRC. In my case, when doing a (niced) compile in background, some windows react very slow, ie Mozilla Thunderbird takes ages to switch trough mails or cliking on an icon in kde to load up konsole takes about 10seconds or more (shoud come up <1sec normally).

Quoted 5 lines

Using 2.8.6.1-ck4

HTH,

Prakash

hmmm, I have tried a number of things, and it seems to be only affected [so far] by heavy NFS use. This was like completely dead. I see that other people are having a hard time w/ CFQ and 2.6.8.1 however all related to swap. I think I will see what I can do w/ 2.6.8.1 and AS.

Now that emerge has finished w/ scanning the portage tree, even though I am reading MP3's from nfs and untar'ing source from NFS all is well.

I can't reboot just now, but soon. Also, right now I am compiling a bunch of updates to Gentoo, and I am experiancing great success. So it could be a regression, but I don't know.

I just tried a couple more things, and am re-scanning w/ emerge, and the behaviour has returned. My rdesktop sessions are as smooth as glass, but anything local is tanking.

thanks,
Joshua

#6 lore raw
In reply to Prakash K. Cheemplavam
Quoted 16 lines · Prakash K. Cheemplavam

Joshua Schmidlkofer wrote:

| I don't know what or why, but I am experiancing a nightmare with
| interactivity and heavy nfs use.   I am using Gentoo, and I have my
| portage tree exported from a central server.   Trying to do an emerge
| update world is taking forever.

[snip]

Yup I think I have a regression here, as well. I remember an older version of ck exhibited this, but the last one for 2.6.7 did work well (I think even the one for 2.8.6-rc4 was ok), IIRC. In my case, when doing a (niced) compile in background, some windows react very slow, ie Mozilla Thunderbird takes ages to switch trough mails or cliking on an icon in kde to load up konsole takes about 10seconds or more (shoud come up <1sec normally).

Quoted 5 lines

Using 2.8.6.1-ck4

HTH,

Prakash

For both of you this only happens with NFS? Can you reproduce the problem in flight and send me the output of 'top -n -n 1' while it's happening? Also if you have time can you confirm this happens with just the staircase patch and none of the other patches?

Cheers,
Con

#7 lore raw
Quoted 17 lines · Con Kolivas
Quoted 16 lines · Prakash K. Cheemplavam

Joshua Schmidlkofer wrote:

| I don't know what or why, but I am experiancing a nightmare with
| interactivity and heavy nfs use.   I am using Gentoo, and I have my
| portage tree exported from a central server.   Trying to do an emerge
| update world is taking forever.

[snip]

Yup I think I have a regression here, as well. I remember an older version of ck exhibited this, but the last one for 2.6.7 did work well (I think even the one for 2.8.6-rc4 was ok), IIRC. In my case, when doing a (niced) compile in background, some windows react very slow, ie Mozilla Thunderbird takes ages to switch trough mails or cliking on an icon in kde to load up konsole takes about 10seconds or more (shoud come up <1sec normally).

Quoted 7 lines
Quoted 5 lines

Using 2.8.6.1-ck4

HTH,

Prakash

For both of you this only happens with NFS? Can you reproduce the problem in flight and send me the output of 'top -n -n 1' while it's happening? Also if you have time can you confirm this happens with just the staircase patch and none of the other patches?

blah... I mean top -b -n 1

Con

#8 lore raw

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

Con Kolivas wrote:

| Con Kolivas writes:
|
|> Prakash K. Cheemplavam wrote:
|>
|>> Yup I think I have a regression here, as well. I remember an older
|>> version of ck exhibited this, but the last one for 2.6.7 did work well
|>> (I think even the one for 2.8.6-rc4 was ok), IIRC. In my case, when
|>> doing a (niced) compile in background, some windows react very slow, ie
|>> Mozilla Thunderbird takes ages to switch trough mails or cliking on an
|>> icon in kde to load up konsole takes about 10seconds or more (shoud come
|>> up <1sec normally).
|>>
|>> Using 2.8.6.1-ck4
|>>
|>> HTH,
|>>
|>> Prakash
|>
|>
|> For both of you this only happens with NFS? Can you reproduce the
|> problem in flight and send me the output of 'top -n -n 1' while it's
|> happening? Also if you have time can you confirm this happens with
|> just the staircase patch and none of the other patches?
|
|
| blah... I mean `top -b -n 1`

SO exactly what I observed, even with the latest test fix. In my first try the machin did even do a hard lock...

So I did a emerge -B xorg-x11 (ie. I started compiling xorg-x11 using gentoo's emerge system). The hard lock occured after a minute or so. Next try I waited only a bit. I clicked on konsole icon to come up, but doesn't want to come for too long. In this time I did the top you see. I'll boot up linux-2.6.8-rc4 and test again (must check first whether it has reiser4 support...). I will also try to back oput staircase and try without.

As you can see xorg-x11 wasn't really compiling ie not using cpu, it was just scaning through the directories to find it it has nothing to do:

make[3]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib' In Datei, eingefügt von ../../config/cf/Imake.tmpl:105,
~ von Imakefile.c:35:
../../config/cf/linux.cf:353: Warnung: "BuildLibGlxWithoutPIC" redefined In Datei, eingefügt von ../../config/cf/site.def:44,
~ von ../../config/cf/Imake.tmpl:46,
~ von Imakefile.c:35:
../../config/cf/host.def:63: Warnung: this is the location of the previous definition
make[3]: Leaving directory /var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib' make[3]: Entering directory /var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU'
making Makefiles in lib/GLU/include...
make[4]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU'
In Datei, eingefügt von ../../../config/cf/Imake.tmpl:105,
~ von Imakefile.c:35:
../../../config/cf/linux.cf:353: Warnung: "BuildLibGlxWithoutPIC" redefined In Datei, eingefügt von ../../../config/cf/site.def:44,
~ von ../../../config/cf/Imake.tmpl:46,
~ von Imakefile.c:35:
../../../config/cf/host.def:63: Warnung: this is the location of the previous definition
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU'
make[4]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU/include' make[4]: Für das Ziel »Makefiles« ist nichts zu tun.
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU/include' making Makefiles in lib/GLU/libutil...
make[4]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU'
In Datei, eingefügt von ../../../config/cf/Imake.tmpl:105,
~ von Imakefile.c:35:
../../../config/cf/linux.cf:353: Warnung: "BuildLibGlxWithoutPIC" redefined In Datei, eingefügt von ../../../config/cf/site.def:44,
~ von ../../../config/cf/Imake.tmpl:46,
~ von Imakefile.c:35:
../../../config/cf/host.def:63: Warnung: this is the location of the previous definition
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU'
make[4]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU/libutil' make[4]: Für das Ziel »Makefiles« ist nichts zu tun.
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU/libutil' making Makefiles in lib/GLU/libtess...
make[4]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU'
In Datei, eingefügt von ../../../config/cf/Imake.tmpl:105,
~ von Imakefile.c:35:
../../../config/cf/linux.cf:353: Warnung: "BuildLibGlxWithoutPIC" redefined In Datei, eingefügt von ../../../config/cf/site.def:44,
~ von ../../../config/cf/Imake.tmpl:46,
~ von Imakefile.c:35:
../../../config/cf/host.def:63: Warnung: this is the location of the previous definition
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU'
make[4]: Entering directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU/libtess' make[4]: Für das Ziel »Makefiles« ist nichts zu tun.
make[4]: Leaving directory `/var/tmp/portage/xorg-x11-6.7.0-r2/work/xc/lib/GLU/libtess' making Makefiles in lib/GLU/libnurbs/internals...

light@tachyon ~ $ top -b -n 1
top - 11:22:41 up 4 min, 4 users, load average: 2.03, 1.20, 0.51

Tasks:  94 total,   4 running,  90 sleeping,   0 stopped,   0 zombie
Cpu(s):  7.4% us, 17.3% sy, 25.2% ni, 25.8% id, 23.6% wa,  0.1% hi,  0.6% si
Mem:   1034224k total,   646380k used,   387844k free,    39220k buffers
Swap:        0k total,        0k used,        0k free,   467460k cached
~  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
~ 5491 root      20   0  151m  20m 141m S  9.9  2.0   0:10.99 X
~ 5662 light     20   0 31616  15m  28m S  4.0  1.5   0:01.32 kdeinit
14859 light     20   0 31152  14m  28m R  2.0  1.5   0:00.33 kdeinit
~    1 root      20   0  1356  416 1204 S  0.0  0.0   0:00.58 init
~    2 root      39  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
~    3 root      10 -10     0    0    0 S  0.0  0.0   0:00.04 events/0
~    4 root      10 -10     0    0    0 S  0.0  0.0   0:00.00 khelper
~    5 root      10 -10     0    0    0 S  0.0  0.0   0:00.00 kacpid
~   29 root      10 -10     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
~   45 root      10 -10     0    0    0 S  0.0  0.0   0:00.00 aio/0
~   44 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kswapd0
~  137 root      10 -10     0    0    0 S  0.0  0.0   0:00.00 ata/0
~  138 root      20   0     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_0
~  139 root      20   0     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_1
~  153 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kseriod
~  159 root      20   0     0    0    0 S  0.0  0.0   0:00.00 i2oevtd
~  185 root      10 -10     0    0    0 S  0.0  0.0   0:00.00 reiserfs/0
~  423 root      10 -10  1332  320 1184 S  0.0  0.0   0:00.02 udevd
~  944 root      20   0     0    0    0 S  0.0  0.0   0:00.00
ktxnmgrd:sda5:w
~  945 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ent:sda5.
~  948 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khubd
~ 2756 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khpsbpkt
~ 2768 root      20   0     0    0    0 S  0.0  0.0   0:00.00 knodemgrd_0
~ 4543 root      20   0  1616  628 1436 S  0.0  0.1   0:00.00 syslog-ng
~ 4877 rpc       20   0  1568  612 1400 S  0.0  0.1   0:00.00 portmap
~ 4880 root      20   0  6620 3568 3100 S  0.0  0.3   0:00.14 cupsd
~ 5031 light     20   0  3116 1520 2504 S  0.0  0.1   0:00.01 famd
~ 5091 nobody    20   0  1528  720 1360 S  0.0  0.1   0:00.00 rpc.statd
~ 5096 root      20   0     0    0    0 S  0.0  0.0   0:00.00 nfsd
~ 5097 root      20   0     0    0    0 S  0.0  0.0   0:00.00 nfsd
~ 5098 root      20   0     0    0    0 S  0.0  0.0   0:00.00 nfsd
~ 5099 root      20   0     0    0    0 S  0.0  0.0   0:00.00 nfsd
~ 5100 root      20   0     0    0    0 S  0.0  0.0   0:00.00 nfsd
~ 5101 root      20   0     0    0    0 S  0.0  0.0   0:00.00 nfsd
~ 5102 root      20   0     0    0    0 S  0.0  0.0   0:00.00 nfsd
~ 5103 root      20   0     0    0    0 S  0.0  0.0   0:00.00 nfsd
~ 5106 root      20   0     0    0    0 S  0.0  0.0   0:00.00 lockd
~ 5107 root      20   0     0    0    0 S  0.0  0.0   0:00.00 rpciod
~ 5108 root      20   0  1568  744 1376 S  0.0  0.1   0:00.00 rpc.mountd
~ 5160 root      20   0  3288 1376 2920 S  0.0  0.1   0:00.00 sshd
~ 5263 root      20   0  2032  896 1704 S  0.0  0.1   0:00.00 xinetd
~ 5315 root      20   0  1404  580 1236 S  0.0  0.1   0:00.00 agetty
~ 5316 root      20   0  1404  580 1236 S  0.0  0.1   0:00.00 agetty
~ 5317 root      20   0  1404  580 1236 S  0.0  0.1   0:00.00 agetty
~ 5318 root      20   0  1404  580 1236 S  0.0  0.1   0:00.00 agetty
~ 5319 root      20   0  1404  580 1236 S  0.0  0.1   0:00.00 agetty
~ 5320 root      20   0  1404  580 1236 S  0.0  0.1   0:00.00 agetty
~ 5478 root      20   0  2560  604 2252 S  0.0  0.1   0:00.00 kdm
~ 5492 root      20   0  3300 1464 2744 S  0.0  0.1   0:00.01 kdm
~ 5551 light     20   0  4360 1004 4180 S  0.0  0.1   0:00.00 kde-3.3.0
~ 5560 light     20   0  4748 1148 4180 S  0.0  0.1   0:00.00 startkde
~ 5616 light     20   0 26324 9768  24m S  0.0  0.9   0:00.08 kdeinit
~ 5619 light     20   0 25200 8476  24m S  0.0  0.8   0:00.01 kdeinit
~ 5621 light     20   0 27360  10m  26m S  0.0  1.0   0:00.05 kdeinit
~ 5624 light     20   0 29972  13m  27m S  0.0  1.3   0:00.24 kdeinit
~ 5630 light     20   0 27128  11m  25m S  0.0  1.1   0:00.07 kdeinit
~ 5640 light     20   0  1344  248 1188 S  0.0  0.0   0:00.00 kwrapper
~ 5642 light     20   0 27184  11m  25m S  0.0  1.1   0:00.06 kdeinit
~ 5643 light     20   0 29104  13m  26m S  0.0  1.4   0:00.52 kdeinit
~ 5645 light     20   0 30264  15m  27m S  0.0  1.5   0:01.00 kdeinit
~ 5647 light     20   0 31808  15m  28m S  0.0  1.6   0:00.68 kdeinit
~ 5648 light     20   0 27976  10m  26m S  0.0  1.0   0:00.00 kdeinit
~ 5650 light     20   0 26420 8404  16m S  0.0  0.8   0:00.74 gkrellm2
~ 5654 light     20   0 28404  13m  25m S  0.0  1.3   0:00.13 kdeinit
~ 5657 light     20   0 27712  11m  25m S  0.0  1.2   0:00.08 kdeinit
~ 5659 light     20   0 30968  14m  28m S  0.0  1.5   0:00.20 korgac
~ 5665 light     20   0  4836 1488 4372 S  0.0  0.1   0:00.00 bash
~ 5674 root      20   0  2144  988 1700 S  0.0  0.1   0:00.00 su
~ 5677 root      20   0  4576 1488 4372 S  0.0  0.1   0:00.00 bash
~ 5692 light     20   0  4620 1120 4180 S  0.0  0.1   0:00.00 thunderbird
~ 5694 light     20   0  4620 1128 4180 S  0.0  0.1   0:00.00 run-mozilla.sh
~ 5699 light     20   0  126m  35m  37m S  0.0  3.5   0:02.90
thunderbird-bin
~ 5727 light     20   0  6004 2352 5564 S  0.0  0.2   0:00.04 gconfd-2
~ 9427 light     20   0  4752 1184 4180 S  0.0  0.1   0:00.00 firefox
~ 9455 light     20   0 83648  32m  36m S  0.0  3.3   0:03.45 firefox-bin
18499 light     20   0  4836 1488 4372 S  0.0  0.1   0:00.00 bash
18536 root      24   4 12512 7176 7432 S  0.0  0.7   0:00.72 emerge
18657 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pdflush
19367 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pdflush
21826 root      24   4  1588  636 1408 S  0.0  0.1   0:00.00 sandbox
21827 root      24   4  6124 2684 4408 S  0.0  0.3   0:00.12 ebuild.sh
21862 root      24   4  4872 1444 4408 S  0.0  0.1   0:00.00 emake
21863 root      24   4  4204 1052 3748 S  0.0  0.1   0:00.00 make
22055 root      24   4  4288 1280 3832 S  0.0  0.1   0:00.00 make
22056 root      24   4  4676 1356 4216 S  0.0  0.1   0:00.00 sh
22318 root      24   4  4288 1208 3832 S  0.0  0.1   0:00.00 make
22319 root      24   4  4676 1360 4216 S  0.0  0.1   0:00.00 sh
22323 light     29   0 28612  11m  26m R  0.0  1.2   0:00.07 kdeinit
22596 light     20   0  1948  896 1736 R  0.0  0.1   0:00.00 top
22652 root      24   4  4288 1200 3832 S  0.0  0.1   0:00.00 make
22653 root      24   4  4672 1332 4216 S  0.0  0.1   0:00.00 sh
22654 root      25   4  1576  616 1248 S  0.0  0.1   0:00.00 imake
22655 root      25   4  4048  808 3608 S  0.0  0.1   0:00.00 gcc
22656 root      25   4  7836 1252 6812 R  0.0  0.1   0:00.00 cc1

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBKwpPxU2n/+9+t5gRAj0QAJ9cCgvd2v8AWtZ4TOtifIM3eLy24gCfflPO yDWBXABxegkw/Eaqd9MFVgs=
=nmxi
-----END PGP SIGNATURE-----

#9 lore raw
Quoted 26 lines · Prakash K. Cheemplavam
|>> version of ck exhibited this, but the last one for 2.6.7 did work well
|>> (I think even the one for 2.8.6-rc4 was ok), IIRC. In my case, when
|>> doing a (niced) compile in background, some windows react very slow, ie
|>> Mozilla Thunderbird takes ages to switch trough mails or cliking on an
|>> icon in kde to load up konsole takes about 10seconds or more (shoud come
|>> up <1sec normally).
|>>> |> For both of you this only happens with NFS? Can you reproduce the
|> problem in flight and send me the output of 'top -n -n 1' while it's
|> happening? Also if you have time can you confirm this happens with
|> just the staircase patch and none of the other patches?
|
|
| blah... I mean `top -b -n 1`

SO exactly what I observed, even with the latest test fix. In my first try the machin did even do a hard lock...

So I did a emerge -B xorg-x11 (ie. I started compiling xorg-x11 using gentoo's emerge system). The hard lock occured after a minute or so. Next try I waited only a bit. I clicked on konsole icon to come up, but doesn't want to come for too long. In this time I did the top you see. I'll boot up linux-2.6.8-rc4 and test again (must check first whether it has reiser4 support...). I will also try to back oput staircase and try without.

Quoted 2 lines

As you can see xorg-x11 wasn't really compiling ie not using cpu, it was just scaning through the directories to find it it has nothing to do:

Does it happen without nfs or not? Does it happen with only the staircase patch or not?

Quoted 6 lines

light@tachyon ~ $ top -b -n 1
top - 11:22:41 up 4 min, 4 users, load average: 2.03, 1.20, 0.51

Tasks:  94 total,   4 running,  90 sleeping,   0 stopped,   0 zombie
Cpu(s):  7.4% us, 17.3% sy, 25.2% ni, 25.8% id, 23.6% wa,  0.1% hi,  0.6% si
Mem:   1034224k total,   646380k used,   387844k free,    39220k buffers
Swap:        0k total,        0k used,        0k free,   467460k cached

You're not hitting swap.

Quoted 3 lines
~  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
~ 5491 root      20   0  151m  20m 141m S  9.9  2.0   0:10.99 X

X is as good priority as it gets.

Quoted 2 lines

~ 5662 light 20 0 31616 15m 28m S 4.0 1.5 0:01.32 kdeinit
14859 light 20 0 31152 14m 28m R 2.0 1.5 0:00.33 kdeinit

So is kde

Quoted 1 line

~ 44 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0

kswapd isn't chewing up cpu time.

In fact nothing is chewing up a lot of cpu time; you're just waiting on i/o

Quoted 1 line

Cpu(s): 7.4% us, 17.3% sy, 25.2% ni, 25.8% id, 23.6% wa, 0.1%

hi, 0.6% si

You even have 25% idle time so you have cpu to spare. Doesn't sound like a scheduling issue but something getting stuck during I/O.

Something else is at play here. I need more information about the questions above.

Con

#10 lore raw

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

Con Kolivas wrote:

| Prakash K. Cheemplavam writes:
| Does it happen without nfs or not? Does it happen with only the
| staircase patch or not?

I don't think in my case it is nfs related. I have compiled it in and nfsd is running, but in my test everything was done locally. I haven't tested the latter, yet. (But will do later.)

|> light@tachyon ~ $ top -b -n 1
|> top - 11:22:41 up 4 min,  4 users,  load average: 2.03, 1.20, 0.51
|> Tasks:  94 total,   4 running,  90 sleeping,   0 stopped,   0 zombie
|> Cpu(s):  7.4% us, 17.3% sy, 25.2% ni, 25.8% id, 23.6% wa,  0.1% hi,
|> 0.6% si
|> Mem:   1034224k total,   646380k used,   387844k free,    39220k buffers
|> Swap:        0k total,        0k used,        0k free,   467460k cached
|
|
| You're not hitting swap.

I am not using one. ;-)

| In fact nothing is chewing up a lot of cpu time; you're just waiting on i/o

|
|> Cpu(s):  7.4% us, 17.3% sy, 25.2% ni, 25.8% id, 23.6% wa,  0.1%
|
| hi,  0.6% si
|
| You even have 25% idle time so you have cpu to spare. Doesn't sound like
| a scheduling issue but something getting stuck during I/O.
| Something else is at play here. I need more information about the
| questions above.

Could it be cfq then? I will reboot an try with as...

Prakash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBKxBzxU2n/+9+t5gRAtgXAJ9XB3LAsF9y/ZhTMBK59zyEjW/xewCfSSWv Wn0IlxxRuuffjOtC1GUNuYU=
=CZSQ
-----END PGP SIGNATURE-----

#11 lore raw
In reply to Con Kolivas
Quoted 2 lines · Con Kolivas

Added since 2.6.8.1-ck3:
+mapped_watermark.diff

Sounds like a bad idea for file servers ;)

Wouldn't it be better to lazily move these cached pages to a "cached" list like the BSDs have, and reclaim it immediately when the memory is needed for something else ?

It should be easy enough to keep the cached data around and still have the cache pages easily reclaimable.

Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
#12 lore raw
Quoted 2 lines · Con Kolivas
Quoted 2 lines

Added since 2.6.8.1-ck3:
+mapped_watermark.diff

Quoted 6 lines · Rik van Riel

Sounds like a bad idea for file servers ;)
Wouldn't it be better to lazily move these cached pages to a "cached" list like the BSDs have, and reclaim it immediately when the memory is needed for something else ?
It should be easy enough to keep the cached data around and still have the cache pages easily reclaimable.

This will be unmapped and clean; but that's not certain to be enough. We must ask at what cost comes aggressive caching.

-- wli

#14 lore raw
In reply to Rik van Riel
Quoted 2 lines · William Lee Irwin III
Quoted 2 lines

This will be unmapped and clean; but that's not certain to be enough. We must ask at what cost comes aggressive caching.

Quoted 1 line · Rik van Riel

Why isn't unmapped and clean enough ?

We don't know that it isn't; it merely remains to be proved that it is.

-- wli

#13 lore raw
In reply to William Lee Irwin III
Quoted 2 lines · William Lee Irwin III

This will be unmapped and clean; but that's not certain to be enough. We must ask at what cost comes aggressive caching.

Why isn't unmapped and clean enough ?

Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
#15 lore raw
In reply to Rik van Riel
Quoted 7 lines · Rik van Riel
Quoted 2 lines · Con Kolivas

Added since 2.6.8.1-ck3:
+mapped_watermark.diff

Quoted 8 lines

Sounds like a bad idea for file servers ;)

Wouldn't it be better to lazily move these cached pages to a "cached" list like the BSDs have, and reclaim it immediately when the memory is needed for something else ?

It should be easy enough to keep the cached data around and still have the cache pages easily reclaimable.

Sounds like a good idea. Would this leave us with large buddies though? Also with file caching it tends to do very little so the ram does indeed fill up still. Furthermore, setting mapped to 0 basically disables it anyway so that shouldn't be an issue. Currently file servers are recommended to tune the "swappiness" value to 100 in the same manner.

This is the buddy condition the machine looks like after it's been running for days with this patch in situ.

cat /proc/buddyinfo
Node 0, zone DMA 15 14 10 11 13 11 9
5 3 1 0
Node 0, zone Normal 15778 17800 6885 722 14 1 3
0 0 1 0

Just FYI here's the current version of the patch.

Cheers,
Con

 include/linux/mmzone.h |    3 +
 include/linux/swap.h   |    2 -
 include/linux/sysctl.h |    2 -
 kernel/sysctl.c        |    8 ++--
 mm/page_alloc.c        |    5 ++
 mm/vmscan.c            |   98 
+++++++++++++++++++++++--------------------------
 6 files changed, 59 insertions(+), 59 deletions(-)
include/linux/mmzone.h +2 -1
Index: linux-2.6.8.1/include/linux/mmzone.h
===================================================================
@@ -125,7 +125,7 @@ struct zone {
 	 */
 	spinlock_t		lock;
 	unsigned long		free_pages;
-	unsigned long		pages_min, pages_low, pages_high;
+	unsigned long		pages_min, pages_low, pages_high, pages_unmapped;
 	/*
 	 * protection[] is a pre-calculated number of extra pages that must be
 	 * available in a zone in order for __alloc_pages() to allocate memory
@@ -276,6 +276,7 @@ typedef struct pglist_data {
 	struct pglist_data *pgdat_next;
 	wait_queue_head_t       kswapd_wait;
 	struct task_struct *kswapd;
+	int maplimit;
 } pg_data_t;
 
 #define node_present_pages(nid)	(NODE_DATA(nid)->node_present_pages)
include/linux/swap.h +1 -1
Index: linux-2.6.8.1/include/linux/swap.h
===================================================================
@@ -174,7 +174,7 @@ extern void swap_setup(void);
 /* linux/mm/vmscan.c */
 extern int try_to_free_pages(struct zone **, unsigned int, unsigned int);
 extern int shrink_all_memory(int);
-extern int vm_swappiness;
+extern int vm_mapped;
 
 #ifdef CONFIG_MMU
 /* linux/mm/shmem.c */
include/linux/sysctl.h +1 -1
Index: linux-2.6.8.1/include/linux/sysctl.h
===================================================================
@@ -157,7 +157,7 @@ enum
 	VM_OVERCOMMIT_RATIO=16, /* percent of RAM to allow overcommit in */
 	VM_PAGEBUF=17,		/* struct: Control pagebuf parameters */
 	VM_HUGETLB_PAGES=18,	/* int: Number of available Huge Pages */
-	VM_SWAPPINESS=19,	/* Tendency to steal mapped memory */
+	VM_MAPPED=19,		/* percent mapped min while evicting cache */
 	VM_LOWER_ZONE_PROTECTION=20,/* Amount of protection of lower zones */
 	VM_MIN_FREE_KBYTES=21,	/* Minimum free kilobytes to maintain */
 	VM_MAX_MAP_COUNT=22,	/* int: Maximum number of mmaps/address-space */
kernel/sysctl.c +4 -4
Index: linux-2.6.8.1/kernel/sysctl.c
===================================================================
@@ -701,10 +701,10 @@ static ctl_table vm_table[] = {
 		.proc_handler	= &proc_dointvec,
 	},
 	{
-		.ctl_name	= VM_SWAPPINESS,
-		.procname	= "swappiness",
-		.data		= &vm_swappiness,
-		.maxlen		= sizeof(vm_swappiness),
+		.ctl_name	= VM_MAPPED,
+		.procname	= "mapped",
+		.data		= &vm_mapped,
+		.maxlen		= sizeof(vm_mapped),
 		.mode		= 0644,
 		.proc_handler	= &proc_dointvec_minmax,
 		.strategy	= &sysctl_intvec,
mm/page_alloc.c +5 -0
Index: linux-2.6.8.1/mm/page_alloc.c
===================================================================
@@ -628,6 +628,10 @@ __alloc_pages(unsigned int gfp_mask, uns
 		 */
 		if (rt_task(p))
 			min -= z->pages_low >> 1;
+		else if (vm_mapped && wait && 
+			z->free_pages < z->pages_unmapped &&
+			z->free_pages > z->pages_low)
+				wakeup_kswapd(z);
 
 		if (z->free_pages >= min ||
 				(!wait && z->free_pages >= z->pages_high)) {
@@ -1905,6 +1909,7 @@ static void setup_per_zone_pages_min(voi
 
 		zone->pages_low = zone->pages_min * 2;
 		zone->pages_high = zone->pages_min * 3;
+		zone->pages_unmapped = zone->present_pages / 3;
 		spin_unlock_irqrestore(&zone->lru_lock, flags);
 	}
 }
mm/vmscan.c +46 -52

192 lines not on this page · raw message