linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).