2.6.8.1-ck4
Subsystems (7)
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
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.diffThis 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 tunableThe 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/mappedThis 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 torecalc_task_priowhich 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.diffDeprected in favour of
mapped_watermarkFull 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.diffCheers,
Con
Quoted 10 lines · Hans Reiser
Quoted 4 lines · Con Kolivas
Added since 2.6.8.1-ck3:
+mapped_watermark.diffThis 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
@@ -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
@@ -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
@@ -159,7 +159,7 @@ enumVM_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
@@ -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
@@ -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
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% /
-----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-----
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
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
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
-----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-----
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.51Tasks: 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
-----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-----
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
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
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
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
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
@@ -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
@@ -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
@@ -157,7 +157,7 @@ enumVM_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
@@ -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
@@ -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