* 2.6.8.1-ck4
@ 2004-08-22 11:17 Con Kolivas
2004-08-22 18:15 ` 2.6.8.1-ck4 Hans Reiser
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Con Kolivas @ 2004-08-22 11:17 UTC (permalink / raw)
To: ck kernel mailing list, linux kernel mailing list
[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-22 11:17 2.6.8.1-ck4 Con Kolivas
@ 2004-08-22 18:15 ` Hans Reiser
2004-08-22 21:37 ` 2.6.8.1-ck4 Con Kolivas
2004-08-23 17:04 ` 2.6.8.1-ck4 Joshua Schmidlkofer
2004-08-25 20:22 ` 2.6.8.1-ck4 Rik van Riel
2 siblings, 1 reply; 16+ messages in thread
From: Hans Reiser @ 2004-08-22 18:15 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck kernel mailing list, linux kernel mailing list
Con Kolivas wrote:
> 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
can you specify lightly with another sentence or two of detail? Thanks,
Hans
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-22 18:15 ` 2.6.8.1-ck4 Hans Reiser
@ 2004-08-22 21:37 ` Con Kolivas
0 siblings, 0 replies; 16+ messages in thread
From: Con Kolivas @ 2004-08-22 21:37 UTC (permalink / raw)
To: Hans Reiser; +Cc: ck kernel mailing list, linux kernel mailing list
[-- Attachment #1.1: Type: text/plain, Size: 1608 bytes --]
Hans Reiser wrote:
> Con Kolivas wrote:
>> 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
Signed-off-by: Con Kolivas <kernel@kolivas.org>
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(-)
[-- Attachment #1.2: mapped_watermark.diff --]
[-- Type: text/x-patch, Size: 9570 bytes --]
Index: linux-2.6.8.1-ck/include/linux/mmzone.h
===================================================================
--- linux-2.6.8.1-ck.orig/include/linux/mmzone.h 2004-08-15 14:08:19.000000000 +1000
+++ linux-2.6.8.1-ck/include/linux/mmzone.h 2004-08-22 14:32:23.000000000 +1000
@@ -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)
Index: linux-2.6.8.1-ck/include/linux/swap.h
===================================================================
--- linux-2.6.8.1-ck.orig/include/linux/swap.h 2004-08-22 10:58:05.000000000 +1000
+++ linux-2.6.8.1-ck/include/linux/swap.h 2004-08-22 15:26:03.000000000 +1000
@@ -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 */
Index: linux-2.6.8.1-ck/include/linux/sysctl.h
===================================================================
--- linux-2.6.8.1-ck.orig/include/linux/sysctl.h 2004-08-22 10:58:05.000000000 +1000
+++ linux-2.6.8.1-ck/include/linux/sysctl.h 2004-08-22 17:46:08.687087009 +1000
@@ -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 */
Index: linux-2.6.8.1-ck/kernel/sysctl.c
===================================================================
--- linux-2.6.8.1-ck.orig/kernel/sysctl.c 2004-08-22 10:58:05.000000000 +1000
+++ linux-2.6.8.1-ck/kernel/sysctl.c 2004-08-22 17:46:08.641094173 +1000
@@ -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,
Index: linux-2.6.8.1-ck/mm/page_alloc.c
===================================================================
--- linux-2.6.8.1-ck.orig/mm/page_alloc.c 2004-08-22 10:58:00.000000000 +1000
+++ linux-2.6.8.1-ck/mm/page_alloc.c 2004-08-22 17:46:06.263464507 +1000
@@ -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);
}
}
Index: linux-2.6.8.1-ck/mm/vmscan.c
===================================================================
--- linux-2.6.8.1-ck.orig/mm/vmscan.c 2004-08-22 10:58:07.000000000 +1000
+++ linux-2.6.8.1-ck/mm/vmscan.c 2004-08-22 18:28:29.565723150 +1000
@@ -115,10 +115,7 @@ struct shrinker {
#define prefetchw_prev_lru_page(_page, _base, _field) do { } while (0)
#endif
-/*
- * From 0 .. 100. Higher means more swappy.
- */
-int vm_swappiness = 60;
+int vm_mapped = 66;
static long total_memory;
static LIST_HEAD(shrinker_list);
@@ -338,7 +335,8 @@ static pageout_t pageout(struct page *pa
/*
* shrink_list adds the number of reclaimed pages to sc->nr_reclaimed
*/
-static int shrink_list(struct list_head *page_list, struct scan_control *sc)
+static int shrink_list(struct list_head *page_list, struct scan_control *sc,
+ int maplimit)
{
LIST_HEAD(ret_pages);
struct pagevec freed_pvec;
@@ -366,6 +364,8 @@ static int shrink_list(struct list_head
goto keep_locked;
sc->nr_scanned++;
+ if (maplimit && page_mapped(page))
+ goto keep_locked;
/* Double the slab pressure for mapped and swapcache pages */
if (page_mapped(page) || PageSwapCache(page))
sc->nr_scanned++;
@@ -543,6 +543,7 @@ static void shrink_cache(struct zone *zo
LIST_HEAD(page_list);
struct pagevec pvec;
int max_scan = sc->nr_to_scan;
+ int maplimit = 0;
pagevec_init(&pvec, 1);
@@ -584,11 +585,12 @@ static void shrink_cache(struct zone *zo
goto done;
max_scan -= nr_scan;
- if (current_is_kswapd())
+ if (current_is_kswapd()) {
mod_page_state_zone(zone, pgscan_kswapd, nr_scan);
- else
+ maplimit = zone->zone_pgdat->maplimit;
+ } else
mod_page_state_zone(zone, pgscan_direct, nr_scan);
- nr_freed = shrink_list(&page_list, sc);
+ nr_freed = shrink_list(&page_list, sc, maplimit);
if (current_is_kswapd())
mod_page_state(kswapd_steal, nr_freed);
mod_page_state_zone(zone, pgsteal, nr_freed);
@@ -648,10 +650,6 @@ refill_inactive_zone(struct zone *zone,
LIST_HEAD(l_active); /* Pages to go onto the active_list */
struct page *page;
struct pagevec pvec;
- int reclaim_mapped = 0;
- long mapped_ratio;
- long distress;
- long swap_tendency;
lru_add_drain();
pgmoved = 0;
@@ -681,42 +679,11 @@ refill_inactive_zone(struct zone *zone,
zone->nr_active -= pgmoved;
spin_unlock_irq(&zone->lru_lock);
- /*
- * `distress' is a measure of how much trouble we're having reclaiming
- * pages. 0 -> no problems. 100 -> great trouble.
- */
- distress = 100 >> zone->prev_priority;
-
- /*
- * The point of this algorithm is to decide when to start reclaiming
- * mapped memory instead of just pagecache. Work out how much memory
- * is mapped.
- */
- mapped_ratio = (sc->nr_mapped * 100) / total_memory;
-
- /*
- * Now decide how much we really want to unmap some pages. The mapped
- * ratio is downgraded - just because there's a lot of mapped memory
- * doesn't necessarily mean that page reclaim isn't succeeding.
- *
- * The distress ratio is important - we don't want to start going oom.
- *
- * A 100% value of vm_swappiness overrides this algorithm altogether.
- */
- swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
-
- /*
- * Now use this metric to decide whether to start moving mapped memory
- * onto the inactive list.
- */
- if (swap_tendency >= 100)
- reclaim_mapped = 1;
-
while (!list_empty(&l_hold)) {
page = lru_to_page(&l_hold);
list_del(&page->lru);
if (page_mapped(page)) {
- if (!reclaim_mapped) {
+ if (zone->zone_pgdat->maplimit) {
list_add(&page->lru, &l_active);
continue;
}
@@ -981,7 +948,7 @@ out:
* the page allocator fallback scheme to ensure that aging of pages is balanced
* across the zones.
*/
-static int balance_pgdat(pg_data_t *pgdat, int nr_pages)
+static int balance_pgdat(pg_data_t *pgdat, int nr_pages, int maplimit)
{
int to_free = nr_pages;
int priority;
@@ -1006,7 +973,15 @@ static int balance_pgdat(pg_data_t *pgda
int all_zones_ok = 1;
int end_zone = 0; /* Inclusive. 0 = ZONE_DMA */
unsigned long lru_pages = 0;
+ int mapped_ratio = sc.nr_mapped * 100 / total_memory;
+ if (maplimit && (mapped_ratio > vm_mapped ||
+ priority < DEF_PRIORITY))
+ /*
+ * Evict pages only if mapped_ratio < vm_mapped and
+ * only do low priority scanning.
+ */
+ goto out;
if (nr_pages == 0) {
/*
* Scan in the highmem->dma direction for the highest
@@ -1019,10 +994,13 @@ static int balance_pgdat(pg_data_t *pgda
priority != DEF_PRIORITY)
continue;
- if (zone->free_pages <= zone->pages_high) {
- end_zone = i;
- goto scan;
+ if (zone->free_pages <= zone->pages_high ||
+ (maplimit && zone->free_pages <=
+ zone->pages_unmapped)) {
+ end_zone = i;
+ goto scan;
}
+
}
goto out;
} else {
@@ -1148,7 +1126,7 @@ static int kswapd(void *p)
schedule();
finish_wait(&pgdat->kswapd_wait, &wait);
- balance_pgdat(pgdat, 0);
+ balance_pgdat(pgdat, 0, pgdat->maplimit);
}
return 0;
}
@@ -1158,11 +1136,14 @@ static int kswapd(void *p)
*/
void wakeup_kswapd(struct zone *zone)
{
- if (zone->free_pages > zone->pages_low)
+ if (zone->free_pages > zone->pages_unmapped)
return;
+ if (zone->free_pages > zone->pages_low)
+ zone->zone_pgdat->maplimit = 1;
if (!waitqueue_active(&zone->zone_pgdat->kswapd_wait))
return;
wake_up_interruptible(&zone->zone_pgdat->kswapd_wait);
+ zone->zone_pgdat->maplimit = 0;
}
#ifdef CONFIG_PM
@@ -1182,7 +1163,7 @@ int shrink_all_memory(int nr_pages)
current->reclaim_state = &reclaim_state;
for_each_pgdat(pgdat) {
int freed;
- freed = balance_pgdat(pgdat, nr_to_free);
+ freed = balance_pgdat(pgdat, nr_to_free, 0);
ret += freed;
nr_to_free -= freed;
if (nr_to_free <= 0)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-22 11:17 2.6.8.1-ck4 Con Kolivas
2004-08-22 18:15 ` 2.6.8.1-ck4 Hans Reiser
@ 2004-08-23 17:04 ` Joshua Schmidlkofer
2004-08-23 17:19 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
2004-08-25 20:22 ` 2.6.8.1-ck4 Rik van Riel
2 siblings, 1 reply; 16+ messages in thread
From: Joshua Schmidlkofer @ 2004-08-23 17:04 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck kernel mailing list, linux kernel mailing list
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% /
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-23 17:04 ` 2.6.8.1-ck4 Joshua Schmidlkofer
@ 2004-08-23 17:19 ` Prakash K. Cheemplavam
2004-08-23 17:31 ` 2.6.8.1-ck4 Joshua Schmidlkofer
2004-08-23 21:48 ` 2.6.8.1-ck4 Con Kolivas
0 siblings, 2 replies; 16+ messages in thread
From: Prakash K. Cheemplavam @ 2004-08-23 17:19 UTC (permalink / raw)
To: Joshua Schmidlkofer
Cc: Con Kolivas, ck kernel mailing list, linux kernel mailing list
-----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-----
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-23 17:19 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
@ 2004-08-23 17:31 ` Joshua Schmidlkofer
2004-08-23 21:48 ` 2.6.8.1-ck4 Con Kolivas
1 sibling, 0 replies; 16+ messages in thread
From: Joshua Schmidlkofer @ 2004-08-23 17:31 UTC (permalink / raw)
To: Prakash K. Cheemplavam, linux kernel mailing list
> 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
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-23 17:19 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
2004-08-23 17:31 ` 2.6.8.1-ck4 Joshua Schmidlkofer
@ 2004-08-23 21:48 ` Con Kolivas
2004-08-23 23:34 ` 2.6.8.1-ck4 Con Kolivas
1 sibling, 1 reply; 16+ messages in thread
From: Con Kolivas @ 2004-08-23 21:48 UTC (permalink / raw)
To: Prakash K. Cheemplavam
Cc: Joshua Schmidlkofer, ck kernel mailing list, linux kernel mailing list
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
Prakash K. Cheemplavam wrote:
> 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
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-23 21:48 ` 2.6.8.1-ck4 Con Kolivas
@ 2004-08-23 23:34 ` Con Kolivas
2004-08-24 9:28 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
0 siblings, 1 reply; 16+ messages in thread
From: Con Kolivas @ 2004-08-23 23:34 UTC (permalink / raw)
To: Con Kolivas
Cc: Prakash K. Cheemplavam, ck kernel mailing list,
Joshua Schmidlkofer, linux kernel mailing list
Con Kolivas writes:
> Prakash K. Cheemplavam wrote:
>> 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
>
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-23 23:34 ` 2.6.8.1-ck4 Con Kolivas
@ 2004-08-24 9:28 ` Prakash K. Cheemplavam
2004-08-24 9:43 ` 2.6.8.1-ck4 Con Kolivas
0 siblings, 1 reply; 16+ messages in thread
From: Prakash K. Cheemplavam @ 2004-08-24 9:28 UTC (permalink / raw)
To: Con Kolivas
Cc: ck kernel mailing list, Joshua Schmidlkofer, linux kernel mailing list
-----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-----
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-24 9:28 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
@ 2004-08-24 9:43 ` Con Kolivas
2004-08-24 9:54 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
0 siblings, 1 reply; 16+ messages in thread
From: Con Kolivas @ 2004-08-24 9:43 UTC (permalink / raw)
To: Prakash K. Cheemplavam
Cc: ck kernel mailing list, Joshua Schmidlkofer, linux kernel mailing list
Prakash K. Cheemplavam writes:
> |>> 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.
>
> 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?
> 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.
>
> ~ 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.
> ~ 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
> ~ 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
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-24 9:43 ` 2.6.8.1-ck4 Con Kolivas
@ 2004-08-24 9:54 ` Prakash K. Cheemplavam
0 siblings, 0 replies; 16+ messages in thread
From: Prakash K. Cheemplavam @ 2004-08-24 9:54 UTC (permalink / raw)
To: Con Kolivas
Cc: ck kernel mailing list, Joshua Schmidlkofer, linux kernel mailing list
-----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-----
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-22 11:17 2.6.8.1-ck4 Con Kolivas
2004-08-22 18:15 ` 2.6.8.1-ck4 Hans Reiser
2004-08-23 17:04 ` 2.6.8.1-ck4 Joshua Schmidlkofer
@ 2004-08-25 20:22 ` Rik van Riel
2004-08-25 20:50 ` 2.6.8.1-ck4 William Lee Irwin III
2004-08-26 0:10 ` 2.6.8.1-ck4 Con Kolivas
2 siblings, 2 replies; 16+ messages in thread
From: Rik van Riel @ 2004-08-25 20:22 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck kernel mailing list, linux kernel mailing list
On Sun, 22 Aug 2004, Con Kolivas wrote:
> 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.
--
"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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-25 20:22 ` 2.6.8.1-ck4 Rik van Riel
@ 2004-08-25 20:50 ` William Lee Irwin III
2004-08-25 20:56 ` 2.6.8.1-ck4 Rik van Riel
2004-08-26 0:10 ` 2.6.8.1-ck4 Con Kolivas
1 sibling, 1 reply; 16+ messages in thread
From: William Lee Irwin III @ 2004-08-25 20:50 UTC (permalink / raw)
To: Rik van Riel
Cc: Con Kolivas, ck kernel mailing list, linux kernel mailing list
On Sun, 22 Aug 2004, Con Kolivas wrote:
>> Added since 2.6.8.1-ck3:
>> +mapped_watermark.diff
On Wed, Aug 25, 2004 at 04:22:32PM -0400, Rik van Riel wrote:
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-25 20:50 ` 2.6.8.1-ck4 William Lee Irwin III
@ 2004-08-25 20:56 ` Rik van Riel
2004-08-25 21:02 ` 2.6.8.1-ck4 William Lee Irwin III
0 siblings, 1 reply; 16+ messages in thread
From: Rik van Riel @ 2004-08-25 20:56 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Con Kolivas, ck kernel mailing list, linux kernel mailing list
On Wed, 25 Aug 2004, William Lee Irwin III wrote:
> 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 ?
--
"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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-25 20:56 ` 2.6.8.1-ck4 Rik van Riel
@ 2004-08-25 21:02 ` William Lee Irwin III
0 siblings, 0 replies; 16+ messages in thread
From: William Lee Irwin III @ 2004-08-25 21:02 UTC (permalink / raw)
To: Rik van Riel
Cc: Con Kolivas, ck kernel mailing list, linux kernel mailing list
On Wed, 25 Aug 2004, William Lee Irwin III wrote:
>> This will be unmapped and clean; but that's not certain to be enough.
>> We must ask at what cost comes aggressive caching.
On Wed, Aug 25, 2004 at 04:56:53PM -0400, Rik van Riel wrote:
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 2.6.8.1-ck4
2004-08-25 20:22 ` 2.6.8.1-ck4 Rik van Riel
2004-08-25 20:50 ` 2.6.8.1-ck4 William Lee Irwin III
@ 2004-08-26 0:10 ` Con Kolivas
1 sibling, 0 replies; 16+ messages in thread
From: Con Kolivas @ 2004-08-26 0:10 UTC (permalink / raw)
To: Rik van Riel; +Cc: ck kernel mailing list, linux kernel mailing list
[-- Attachment #1.1: Type: text/plain, Size: 1525 bytes --]
Rik van Riel wrote:
> On Sun, 22 Aug 2004, Con Kolivas wrote:
>
>
>>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.
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(-)
[-- Attachment #1.2: mapped_watermark2.diff --]
[-- Type: text/x-patch, Size: 10039 bytes --]
Index: linux-2.6.8.1/include/linux/mmzone.h
===================================================================
--- linux-2.6.8.1.orig/include/linux/mmzone.h 2004-08-15 14:08:19.000000000 +1000
+++ linux-2.6.8.1/include/linux/mmzone.h 2004-08-26 10:01:38.153695699 +1000
@@ -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)
Index: linux-2.6.8.1/include/linux/swap.h
===================================================================
--- linux-2.6.8.1.orig/include/linux/swap.h 2004-08-15 14:08:19.000000000 +1000
+++ linux-2.6.8.1/include/linux/swap.h 2004-08-26 10:01:38.154695545 +1000
@@ -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 */
Index: linux-2.6.8.1/include/linux/sysctl.h
===================================================================
--- linux-2.6.8.1.orig/include/linux/sysctl.h 2004-08-15 14:08:19.000000000 +1000
+++ linux-2.6.8.1/include/linux/sysctl.h 2004-08-26 10:01:38.155695390 +1000
@@ -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 */
Index: linux-2.6.8.1/kernel/sysctl.c
===================================================================
--- linux-2.6.8.1.orig/kernel/sysctl.c 2004-08-15 14:08:19.000000000 +1000
+++ linux-2.6.8.1/kernel/sysctl.c 2004-08-26 10:01:38.156695236 +1000
@@ -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,
Index: linux-2.6.8.1/mm/page_alloc.c
===================================================================
--- linux-2.6.8.1.orig/mm/page_alloc.c 2004-08-15 14:08:19.000000000 +1000
+++ linux-2.6.8.1/mm/page_alloc.c 2004-08-26 10:01:42.205069628 +1000
@@ -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);
}
}
Index: linux-2.6.8.1/mm/vmscan.c
===================================================================
--- linux-2.6.8.1.orig/mm/vmscan.c 2004-08-15 14:08:19.000000000 +1000
+++ linux-2.6.8.1/mm/vmscan.c 2004-08-26 10:01:42.207069319 +1000
@@ -115,10 +115,7 @@ struct shrinker {
#define prefetchw_prev_lru_page(_page, _base, _field) do { } while (0)
#endif
-/*
- * From 0 .. 100. Higher means more swappy.
- */
-int vm_swappiness = 60;
+int vm_mapped = 66;
static long total_memory;
static LIST_HEAD(shrinker_list);
@@ -338,7 +335,8 @@ static pageout_t pageout(struct page *pa
/*
* shrink_list adds the number of reclaimed pages to sc->nr_reclaimed
*/
-static int shrink_list(struct list_head *page_list, struct scan_control *sc)
+static int shrink_list(struct list_head *page_list, struct scan_control *sc,
+ int maplimit)
{
LIST_HEAD(ret_pages);
struct pagevec freed_pvec;
@@ -366,6 +364,8 @@ static int shrink_list(struct list_head
goto keep_locked;
sc->nr_scanned++;
+ if (maplimit && page_mapped(page))
+ goto keep_locked;
/* Double the slab pressure for mapped and swapcache pages */
if (page_mapped(page) || PageSwapCache(page))
sc->nr_scanned++;
@@ -543,6 +543,7 @@ static void shrink_cache(struct zone *zo
LIST_HEAD(page_list);
struct pagevec pvec;
int max_scan = sc->nr_to_scan;
+ int maplimit = 0;
pagevec_init(&pvec, 1);
@@ -584,11 +585,12 @@ static void shrink_cache(struct zone *zo
goto done;
max_scan -= nr_scan;
- if (current_is_kswapd())
+ if (current_is_kswapd()) {
mod_page_state_zone(zone, pgscan_kswapd, nr_scan);
- else
+ maplimit = zone->zone_pgdat->maplimit;
+ } else
mod_page_state_zone(zone, pgscan_direct, nr_scan);
- nr_freed = shrink_list(&page_list, sc);
+ nr_freed = shrink_list(&page_list, sc, maplimit);
if (current_is_kswapd())
mod_page_state(kswapd_steal, nr_freed);
mod_page_state_zone(zone, pgsteal, nr_freed);
@@ -648,10 +650,6 @@ refill_inactive_zone(struct zone *zone,
LIST_HEAD(l_active); /* Pages to go onto the active_list */
struct page *page;
struct pagevec pvec;
- int reclaim_mapped = 0;
- long mapped_ratio;
- long distress;
- long swap_tendency;
lru_add_drain();
pgmoved = 0;
@@ -681,42 +679,11 @@ refill_inactive_zone(struct zone *zone,
zone->nr_active -= pgmoved;
spin_unlock_irq(&zone->lru_lock);
- /*
- * `distress' is a measure of how much trouble we're having reclaiming
- * pages. 0 -> no problems. 100 -> great trouble.
- */
- distress = 100 >> zone->prev_priority;
-
- /*
- * The point of this algorithm is to decide when to start reclaiming
- * mapped memory instead of just pagecache. Work out how much memory
- * is mapped.
- */
- mapped_ratio = (sc->nr_mapped * 100) / total_memory;
-
- /*
- * Now decide how much we really want to unmap some pages. The mapped
- * ratio is downgraded - just because there's a lot of mapped memory
- * doesn't necessarily mean that page reclaim isn't succeeding.
- *
- * The distress ratio is important - we don't want to start going oom.
- *
- * A 100% value of vm_swappiness overrides this algorithm altogether.
- */
- swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
-
- /*
- * Now use this metric to decide whether to start moving mapped memory
- * onto the inactive list.
- */
- if (swap_tendency >= 100)
- reclaim_mapped = 1;
-
while (!list_empty(&l_hold)) {
page = lru_to_page(&l_hold);
list_del(&page->lru);
if (page_mapped(page)) {
- if (!reclaim_mapped) {
+ if (zone->zone_pgdat->maplimit) {
list_add(&page->lru, &l_active);
continue;
}
@@ -981,7 +948,7 @@ out:
* the page allocator fallback scheme to ensure that aging of pages is balanced
* across the zones.
*/
-static int balance_pgdat(pg_data_t *pgdat, int nr_pages)
+static int balance_pgdat(pg_data_t *pgdat, int nr_pages, int maplimit)
{
int to_free = nr_pages;
int priority;
@@ -994,6 +961,20 @@ static int balance_pgdat(pg_data_t *pgda
sc.may_writepage = 0;
sc.nr_mapped = read_page_state(nr_mapped);
+ /*
+ * Sanity check to ensure we don't have a stale maplimit set
+ * and are calling balance_pgdat for a different reason.
+ */
+ if (nr_pages)
+ maplimit = 0;
+ /*
+ * kswapd does a light balance_pgdat() when there is less than 1/3
+ * ram free provided there is less than vm_mapped % of that ram
+ * mapped.
+ */
+ if (maplimit && sc.nr_mapped * 100 / total_memory > vm_mapped)
+ return 0;
+
inc_page_state(pageoutrun);
for (i = 0; i < pgdat->nr_zones; i++) {
@@ -1007,6 +988,12 @@ static int balance_pgdat(pg_data_t *pgda
int end_zone = 0; /* Inclusive. 0 = ZONE_DMA */
unsigned long lru_pages = 0;
+ /*
+ * Only do low priority scanning if we're here due to
+ * mapped watermark.
+ */
+ if (maplimit && priority < DEF_PRIORITY)
+ goto out;
if (nr_pages == 0) {
/*
* Scan in the highmem->dma direction for the highest
@@ -1019,10 +1006,13 @@ static int balance_pgdat(pg_data_t *pgda
priority != DEF_PRIORITY)
continue;
- if (zone->free_pages <= zone->pages_high) {
- end_zone = i;
- goto scan;
+ if (zone->free_pages <= zone->pages_high ||
+ (maplimit && zone->free_pages <=
+ zone->pages_unmapped)) {
+ end_zone = i;
+ goto scan;
}
+
}
goto out;
} else {
@@ -1148,7 +1138,7 @@ static int kswapd(void *p)
schedule();
finish_wait(&pgdat->kswapd_wait, &wait);
- balance_pgdat(pgdat, 0);
+ balance_pgdat(pgdat, 0, pgdat->maplimit);
}
return 0;
}
@@ -1158,11 +1148,15 @@ static int kswapd(void *p)
*/
void wakeup_kswapd(struct zone *zone)
{
+ if (zone->free_pages > zone->pages_unmapped)
+ goto out;
if (zone->free_pages > zone->pages_low)
- return;
+ zone->zone_pgdat->maplimit = 1;
if (!waitqueue_active(&zone->zone_pgdat->kswapd_wait))
- return;
+ goto out;
wake_up_interruptible(&zone->zone_pgdat->kswapd_wait);
+out:
+ zone->zone_pgdat->maplimit = 0;
}
#ifdef CONFIG_PM
@@ -1182,7 +1176,7 @@ int shrink_all_memory(int nr_pages)
current->reclaim_state = &reclaim_state;
for_each_pgdat(pgdat) {
int freed;
- freed = balance_pgdat(pgdat, nr_to_free);
+ freed = balance_pgdat(pgdat, nr_to_free, 0);
ret += freed;
nr_to_free -= freed;
if (nr_to_free <= 0)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2004-08-26 0:12 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-22 11:17 2.6.8.1-ck4 Con Kolivas
2004-08-22 18:15 ` 2.6.8.1-ck4 Hans Reiser
2004-08-22 21:37 ` 2.6.8.1-ck4 Con Kolivas
2004-08-23 17:04 ` 2.6.8.1-ck4 Joshua Schmidlkofer
2004-08-23 17:19 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
2004-08-23 17:31 ` 2.6.8.1-ck4 Joshua Schmidlkofer
2004-08-23 21:48 ` 2.6.8.1-ck4 Con Kolivas
2004-08-23 23:34 ` 2.6.8.1-ck4 Con Kolivas
2004-08-24 9:28 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
2004-08-24 9:43 ` 2.6.8.1-ck4 Con Kolivas
2004-08-24 9:54 ` 2.6.8.1-ck4 Prakash K. Cheemplavam
2004-08-25 20:22 ` 2.6.8.1-ck4 Rik van Riel
2004-08-25 20:50 ` 2.6.8.1-ck4 William Lee Irwin III
2004-08-25 20:56 ` 2.6.8.1-ck4 Rik van Riel
2004-08-25 21:02 ` 2.6.8.1-ck4 William Lee Irwin III
2004-08-26 0:10 ` 2.6.8.1-ck4 Con Kolivas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).