* [PATCH] VM kswapd autotuning vs. -ac7
@ 2000-06-01 22:31 Rik van Riel
2000-06-02 15:54 ` Christoph Rohland
0 siblings, 1 reply; 21+ messages in thread
From: Rik van Riel @ 2000-06-01 22:31 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-mm, linux-kernel
Hi,
this patch does the following things:
- move the starting page age to below the PG_AGE_ADV, so
reclaimed pages have an advantage over pages which are
new in the lru queue
- add two missing wake_up calls to buffer.c (I'm not 100%
sure about these; I found them when digging through the
classzone patch and they are consistent with other uses
of the unused_list_lock
- if try_to_free_buffers waits on a page with buffers and
succeeds in freeing them, return success (partly mined
from classzone)
- __alloc_pages is responsible for waking up kswapd, however
there seemed to be some flaws in the wakeup logic:
- if kswapd is woken up too early, we free too much memory
and waste CPU time
- if kswapd is woken up too late, processes will call
try_to_free_pages() themselves and stall; extremely
bad for performance
The obvious solution is to have an auto-tuning algorithm where
the system tunes how often kswapd is woken up. To do that we
use the zone->zone_wake_kswapd and zone->low_on_memory flags.
Basically kswapd will always continue until no zone is low on
memory any more, sometimes resulting in one zone which has too
much free memory.
If we can keep all zones from being low on memory, allocations
can succeed immediately and applications can run fast. To ensure
that we must wake up kswapd often enough (but not too often).
The goal is to have every allocation happen in the second
"alloc loop" without any zones running low on memory. We achieve
this by waking up kswapd whenever we fall through the first loop
and it was longer than kswapd_pause ago that we last woke up
kswapd.
If we get a zone low on memory, we will half the value of
kswapd_pause so next time we'll wake up kswapd earlier. When
we never get low on memory, kswapd_pause will grow slowly over
time, balancing the halving of the period we did earlier.
I'm running some tests now and it seems that system performance
is good, kswapd overhead is quite a bit lower than before and
the amount of free memory is very stable (between freepages.low
and freepages.high, as it was called in 2.2 ;))
Please give this patch some exposure...
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--- linux-2.4.0-t1-ac7/fs/buffer.c.orig Thu Jun 1 10:37:59 2000
+++ linux-2.4.0-t1-ac7/fs/buffer.c Thu Jun 1 14:51:14 2000
@@ -1868,6 +1868,7 @@
}
spin_unlock(&unused_list_lock);
+ wake_up(&buffer_wait);
return iosize;
}
@@ -2004,6 +2005,8 @@
__put_unused_buffer_head(bh[bhind]);
}
spin_unlock(&unused_list_lock);
+ wake_up(&buffer_wait);
+
goto finished;
}
@@ -2181,6 +2184,12 @@
}
/*
+ * Can the buffer be thrown out?
+ */
+#define BUFFER_BUSY_BITS ((1<<BH_Dirty) | (1<<BH_Lock) | (1<<BH_Protected))
+#define buffer_busy(bh) (atomic_read(&(bh)->b_count) | ((bh)->b_state & BUFFER_BUSY_BITS))
+
+/*
* Sync all the buffers on one page..
*
* If we have old buffers that are locked, we'll
@@ -2190,7 +2199,7 @@
* This all is required so that we can free up memory
* later.
*/
-static void sync_page_buffers(struct buffer_head *bh, int wait)
+static int sync_page_buffers(struct buffer_head *bh, int wait)
{
struct buffer_head * tmp = bh;
@@ -2203,13 +2212,17 @@
} else if (buffer_dirty(p))
ll_rw_block(WRITE, 1, &p);
} while (tmp != bh);
-}
-/*
- * Can the buffer be thrown out?
- */
-#define BUFFER_BUSY_BITS ((1<<BH_Dirty) | (1<<BH_Lock) | (1<<BH_Protected))
-#define buffer_busy(bh) (atomic_read(&(bh)->b_count) | ((bh)->b_state & BUFFER_BUSY_BITS))
+ do {
+ struct buffer_head *p = tmp;
+ tmp = tmp->b_this_page;
+ if (buffer_busy(p))
+ return 0;
+ } while (tmp != bh);
+
+ /* Success. Now try_to_free_buffers can free the page. */
+ return 1;
+}
/*
* try_to_free_buffers() checks if all the buffers on this particular page
@@ -2227,6 +2240,7 @@
struct buffer_head * tmp, * bh = page->buffers;
int index = BUFSIZE_INDEX(bh->b_size);
+again:
spin_lock(&lru_list_lock);
write_lock(&hash_table_lock);
spin_lock(&free_list[index].lock);
@@ -2272,7 +2286,8 @@
spin_unlock(&free_list[index].lock);
write_unlock(&hash_table_lock);
spin_unlock(&lru_list_lock);
- sync_page_buffers(bh, wait);
+ if (sync_page_buffers(bh, wait))
+ goto again;
return 0;
}
--- linux-2.4.0-t1-ac7/mm/page_alloc.c.orig Wed May 31 14:08:50 2000
+++ linux-2.4.0-t1-ac7/mm/page_alloc.c Thu Jun 1 16:56:43 2000
@@ -222,6 +222,8 @@
{
zone_t **zone = zonelist->zones;
extern wait_queue_head_t kswapd_wait;
+ static int last_woke_kswapd;
+ static int kswapd_pause = HZ;
/*
* (If anyone calls gfp from interrupts nonatomically then it
@@ -248,9 +250,22 @@
}
}
- /* All zones are in need of kswapd. */
- if (waitqueue_active(&kswapd_wait))
+ /*
+ * Kswapd should be freeing enough memory to satisfy all allocations
+ * immediately. Calling try_to_free_pages from processes will slow
+ * down the system a lot. On the other hand, waking up kswapd too
+ * often means wasted memory and cpu time.
+ *
+ * We tune the kswapd pause interval in such a way that kswapd is
+ * always just agressive enough to free the amount of memory we
+ * want freed.
+ */
+ if (waitqueue_active(&kswapd_wait) &&
+ time_after(jiffies, last_woke_kswapd + kswapd_pause)) {
+ kswapd_pause++;
+ last_woke_kswapd = jiffies;
wake_up_interruptible(&kswapd_wait);
+ }
/*
* Ok, we don't have any zones that don't need some
@@ -267,6 +282,11 @@
z->low_on_memory = 1;
if (page)
return page;
+ } else {
+ /* We didn't kick kswapd often enough... */
+ kswapd_pause /= 2;
+ if (waitqueue_active(&kswapd_wait))
+ wake_up_interruptible(&kswapd_wait);
}
}
--- linux-2.4.0-t1-ac7/mm/filemap.c.orig Wed May 31 14:08:50 2000
+++ linux-2.4.0-t1-ac7/mm/filemap.c Thu Jun 1 12:15:58 2000
@@ -334,13 +334,6 @@
count--;
/*
- * Page is from a zone we don't care about.
- * Don't drop page cache entries in vain.
- */
- if (page->zone->free_pages > page->zone->pages_high)
- goto dispose_continue;
-
- /*
* Avoid unscalable SMP locking for pages we can
* immediate tell are untouchable..
*/
@@ -374,6 +367,13 @@
goto made_buffer_progress;
}
}
+
+ /*
+ * Page is from a zone we don't care about.
+ * Don't drop page cache entries in vain.
+ */
+ if (page->zone->free_pages > page->zone->pages_high)
+ goto unlock_continue;
/* Take the pagecache_lock spinlock held to avoid
other tasks to notice the page while we are looking at its
--- linux-2.4.0-t1-ac7/include/linux/swap.h.orig Wed May 31 21:00:06 2000
+++ linux-2.4.0-t1-ac7/include/linux/swap.h Thu Jun 1 11:51:25 2000
@@ -166,7 +166,7 @@
* The 2.4 code, however, is mostly simple and stable ;)
*/
#define PG_AGE_MAX 64
-#define PG_AGE_START 5
+#define PG_AGE_START 2
#define PG_AGE_ADV 3
#define PG_AGE_DECL 1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-01 22:31 [PATCH] VM kswapd autotuning vs. -ac7 Rik van Riel
@ 2000-06-02 15:54 ` Christoph Rohland
2000-06-02 16:01 ` Rik van Riel
0 siblings, 1 reply; 21+ messages in thread
From: Christoph Rohland @ 2000-06-02 15:54 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-mm
Hi Rik,
This patch still does not allow swapping with shm. Instead it kills
all runnable processes without message.
Greetings
Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-02 15:54 ` Christoph Rohland
@ 2000-06-02 16:01 ` Rik van Riel
2000-06-03 9:02 ` Christoph Rohland
0 siblings, 1 reply; 21+ messages in thread
From: Rik van Riel @ 2000-06-02 16:01 UTC (permalink / raw)
To: Christoph Rohland; +Cc: linux-mm
On 2 Jun 2000, Christoph Rohland wrote:
> This patch still does not allow swapping with shm. Instead it
> kills all runnable processes without message.
As I said before, I haven't touched the SHM code at all.
Also, the shmtest test program runs fine here (except for
reduced system responsiveness)...
I'm quite interested in how you make your system die by
using SHM. I haven't succeeded in doing so here...
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-02 16:01 ` Rik van Riel
@ 2000-06-03 9:02 ` Christoph Rohland
2000-06-03 20:47 ` Rik van Riel
0 siblings, 1 reply; 21+ messages in thread
From: Christoph Rohland @ 2000-06-03 9:02 UTC (permalink / raw)
To: Rik van Riel; +Cc: Christoph Rohland, linux-mm
Rik van Riel <riel@conectiva.com.br> writes:
> On 2 Jun 2000, Christoph Rohland wrote:
>
> > This patch still does not allow swapping with shm. Instead it
> > kills all runnable processes without message.
>
> As I said before, I haven't touched the SHM code at all.
> Also, the shmtest test program runs fine here (except for
> reduced system responsiveness)...
>
> I'm quite interested in how you make your system die by
> using SHM. I haven't succeeded in doing so here...
Simply by running
./ipctst 10 666000000 10 31 20&
./ipctst 16 666000000 2 31 20&
But I have to correct me. It does not kill all runnable processes, but
all I am using like ipctst, vmstat and xterm.
Greetings
Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-03 9:02 ` Christoph Rohland
@ 2000-06-03 20:47 ` Rik van Riel
2000-06-04 11:12 ` Christoph Rohland
0 siblings, 1 reply; 21+ messages in thread
From: Rik van Riel @ 2000-06-03 20:47 UTC (permalink / raw)
To: Christoph Rohland; +Cc: linux-mm
On 3 Jun 2000, Christoph Rohland wrote:
> Rik van Riel <riel@conectiva.com.br> writes:
> > On 2 Jun 2000, Christoph Rohland wrote:
> >
> > > This patch still does not allow swapping with shm. Instead it
> > > kills all runnable processes without message.
>
> Simply by running
>
> ./ipctst 10 666000000 10 31 20&
> ./ipctst 16 666000000 2 31 20&
>
> But I have to correct me. It does not kill all runnable
> processes, but all I am using like ipctst, vmstat and xterm.
Patch #2 indeed had a big bug that made all systems crash instead
of use swap (missing braces next to a goto), does patch #3 give you
the same behaviour?
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-03 20:47 ` Rik van Riel
@ 2000-06-04 11:12 ` Christoph Rohland
2000-06-05 8:58 ` Christoph Rohland
0 siblings, 1 reply; 21+ messages in thread
From: Christoph Rohland @ 2000-06-04 11:12 UTC (permalink / raw)
To: Rik van Riel; +Cc: Christoph Rohland, linux-mm
Rik van Riel <riel@conectiva.com.br> writes:
> Patch #2 indeed had a big bug that made all systems crash instead
> of use swap (missing braces next to a goto), does patch #3 give you
> the same behaviour?
>From a short view #3 looks much better, but one thing is disturbing me:
12 0 0 0 492440 1604 10200 0 0 0 0 104 72356 5 94 1
shmget: Cannot allocate memory
9 2 1 8992 610136 148 13840 0 1798 3 452 1581 83181 0 90 9
it begins swapping with 490MB free and fails to allocate a shm segment?
Greetings
Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-04 11:12 ` Christoph Rohland
@ 2000-06-05 8:58 ` Christoph Rohland
2000-06-05 10:16 ` Rik van Riel
0 siblings, 1 reply; 21+ messages in thread
From: Christoph Rohland @ 2000-06-05 8:58 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-mm
Christoph Rohland <cr@sap.com> writes:
> From a short view #3 looks much better, but one thing is disturbing me:
>
> 12 0 0 0 492440 1604 10200 0 0 0 0 104 72356 5 94 1
> shmget: Cannot allocate memory
> 9 2 1 8992 610136 148 13840 0 1798 3 452 1581 83181 0 90 9
>
> it begins swapping with 490MB free and fails to allocate a shm segment?
O.k. more (not that nice) data from the same run:
3 9 1 235720 2404 96 12576 58 18585 21 4648 13905 35860 0 85
15
VM: killing process ipctst
4 6 1 11004 113588 100 19804 78 39615 20 9904 2542 27828 0 16 83
VM: killing process ipctst
VM: killing process ipctst
shmget: Cannot allocate memory
VM: killing process ipctst
3 3 1 109996 3176 96 13884 239 20720 63 5180 1312 132803 1 38
61
VM: killing process ipctst
0 5 1 264652 2012 96 13544 2 30912 0 7728 1636 11053 0 10 90
[...] Killing until only one ipctst is running and then a long time no swap
1 0 0 282760 606512 116 11360 0 0 0 0 107 1272 1 11 87
1 0 0 282760 656164 116 11360 0 0 0 0 103 2 1 12 87
1 0 0 282760 4664 116 11360 0 0 0 0 105 2 1 12 87
4294967295 1 1 323808 2032 96 12828 1 8226 0 2057 533 1600 1 7 92
VM: killing process vmstat
VM: killing process bash
VM: killing process init
NMI Watchdog detected LOCKUP on CPU6, registers: CPU: 6
EIP: 0010:[<c011efed>]
EFLAGS: 00000002
eax: c1088000 ebx: f7400000 ecx: c02c20a4 edx: c02c20a4
esi: 00000368 edi: c1088000 ebp: c1088000 esp: c1089eec
ds: 0018 es: 0018 ss: 0018
Process init (pid: 1, stackpage=c1089000)
Stack: c1088000 c0289c60 00000009 08050054 c011f362 00000004 c3fce05c c1088000
c0114304 00000009 c1088000 0804ff80 40105720 bffff68c c3fcc200 c3fce078
c3fce078 c3fce05c c3fce040 bffffa50 bffff9d0 00030002 ffffffff c1089fa4
Call Trace: [<c011f362>] [<c0114304>] [<c010b125>]
Call Trace: [<c011f362>] [<c0114304>] [<c010b125>]
Code: 89 83 80 00 00 00 8b 80 84 00 00 00 89 83 8c 00 00 00 85 c0
>>EIP; c011efed <exit_notify+165/270> <=====
Trace; c011f362 <do_exit+26a/2ac>
Trace; c0114304 <do_page_fault+4b4/570>
Trace; c010b125 <error_code+2d/38>
Code: 89 83 80 00 00 00 8b 80 84 00 00 00 89 83 8c 00 00 00 85 c0
Code; c011efed <exit_notify+165/270>
00000000 <_EIP>:
Code; c011efed <exit_notify+165/270> <=====
0: 89 83 80 00 00 00 movl %eax,0x80(%ebx) <=====
Code; c011eff3 <exit_notify+16b/270>
6: 8b 80 84 00 00 00 movl 0x84(%eax),%eax
Code; c011eff9 <exit_notify+171/270>
c: 89 83 8c 00 00 00 movl %eax,0x8c(%ebx)
Code; c011efff <exit_notify+177/270>
12: 85 c0 testl %eax,%eax
console shuts up ...
Please note the ridiculous vmstat output before/while going
berserk. (But at least the kernel now notifies again when killing
processes)
Greetings
Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-05 8:58 ` Christoph Rohland
@ 2000-06-05 10:16 ` Rik van Riel
2000-06-07 10:23 ` Christoph Rohland
0 siblings, 1 reply; 21+ messages in thread
From: Rik van Riel @ 2000-06-05 10:16 UTC (permalink / raw)
To: Christoph Rohland; +Cc: linux-mm
On 5 Jun 2000, Christoph Rohland wrote:
> O.k. more (not that nice) data from the same run:
Awaiting your promised integration of SHM with the shrink_mmap
queue...
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-05 10:16 ` Rik van Riel
@ 2000-06-07 10:23 ` Christoph Rohland
2000-06-07 12:43 ` Rik van Riel
2000-06-07 13:32 ` [PATCH] VM kswapd autotuning vs. -ac7 Stephen C. Tweedie
0 siblings, 2 replies; 21+ messages in thread
From: Christoph Rohland @ 2000-06-07 10:23 UTC (permalink / raw)
To: Rik van Riel; +Cc: Christoph Rohland, linux-mm
Rik van Riel <riel@conectiva.com.br> writes:
> Awaiting your promised integration of SHM with the shrink_mmap
> queue...
Sorry Rik, there was a misunderstanding here. I would really like to
have this integration. But AFAICS this is a major task. shrink_mmap
relies on the pages to be in the page cache and the pagecache does not
handle shared anonymous pages.
Thus shm does it's own page handling and swap out mechanism. Since I
do not know enough about the page cache I will not do this before
2.5. If you think it can be easily done, feel free to do it yourself
or show me the way to go (But I will be on vacation the next two
weeks).
Greetings
Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 10:23 ` Christoph Rohland
@ 2000-06-07 12:43 ` Rik van Riel
2000-06-07 13:04 ` Christoph Rohland
2000-06-07 13:32 ` [PATCH] VM kswapd autotuning vs. -ac7 Stephen C. Tweedie
1 sibling, 1 reply; 21+ messages in thread
From: Rik van Riel @ 2000-06-07 12:43 UTC (permalink / raw)
To: Christoph Rohland; +Cc: linux-mm
On 7 Jun 2000, Christoph Rohland wrote:
> Rik van Riel <riel@conectiva.com.br> writes:
>
> > Awaiting your promised integration of SHM with the shrink_mmap
> > queue...
>
> Sorry Rik, there was a misunderstanding here. I would really
> like to have this integration. But AFAICS this is a major task.
> shrink_mmap relies on the pages to be in the page cache and the
> pagecache does not handle shared anonymous pages.
Ahh, but it could easily swap them out when the last of the
pages is unmapped.
if (PageSHM(page) && not_in_use(page) && PageDirty(page)) {
swapentry_t entry;
entry.val = alloc_swap_entry();
....
rw_swap_page(page);
}
And the next time it can be freed like a normal SwapCache
page...
> Thus shm does it's own page handling and swap out mechanism.
> Since I do not know enough about the page cache I will not do
> this before 2.5. If you think it can be easily done, feel free
> to do it yourself or show me the way to go (But I will be on
> vacation the next two weeks).
OK. The shrink_mmap() side of the story should be relatively
easy (see above), but the ipc/shm.c part is a complete mystery
to me ... ;(
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 12:43 ` Rik van Riel
@ 2000-06-07 13:04 ` Christoph Rohland
2000-06-07 13:39 ` Rik van Riel
0 siblings, 1 reply; 21+ messages in thread
From: Christoph Rohland @ 2000-06-07 13:04 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-mm
Rik van Riel <riel@conectiva.com.br> writes:
> Ahh, but it could easily swap them out when the last of the
> pages is unmapped.
>
> if (PageSHM(page) && not_in_use(page) && PageDirty(page)) {
> swapentry_t entry;
> entry.val = alloc_swap_entry();
> ....
> rw_swap_page(page);
> }
>
> And the next time it can be freed like a normal SwapCache
> page...
O.K. So what do I test in PageSHM()? Right now there is no such flag.
> > Thus shm does it's own page handling and swap out mechanism.
> > Since I do not know enough about the page cache I will not do
> > this before 2.5. If you think it can be easily done, feel free
> > to do it yourself or show me the way to go (But I will be on
> > vacation the next two weeks).
>
> OK. The shrink_mmap() side of the story should be relatively
> easy (see above), but the ipc/shm.c part is a complete mystery
> to me ... ;(
You see and for me it's vice versa. The shm part is relatively
easy. Pages in shm do not get introduced into any other cache unless
they are swapped out. shm uses a very dumb algorithm to find swappable
pages when shm_swap is called.
If we want to introduce the shm pages into the lru lists, we need a
mark as shm page. Then we could perhaps make shm_swap obsolete and
leave the work to shrink_mmap. But shrink_mmap is new to me...
Greetings
Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 10:23 ` Christoph Rohland
2000-06-07 12:43 ` Rik van Riel
@ 2000-06-07 13:32 ` Stephen C. Tweedie
2000-06-07 14:09 ` Jamie Lokier
2000-06-07 14:11 ` Christoph Rohland
1 sibling, 2 replies; 21+ messages in thread
From: Stephen C. Tweedie @ 2000-06-07 13:32 UTC (permalink / raw)
To: Christoph Rohland; +Cc: Rik van Riel, linux-mm
Hi,
On Wed, Jun 07, 2000 at 12:23:36PM +0200, Christoph Rohland wrote:
> Rik van Riel <riel@conectiva.com.br> writes:
>
> > Awaiting your promised integration of SHM with the shrink_mmap
> > queue...
>
> Sorry Rik, there was a misunderstanding here. I would really like to
> have this integration. But AFAICS this is a major task. shrink_mmap
> relies on the pages to be in the page cache and the pagecache does not
> handle shared anonymous pages.
The swap cache --- which does handle anonymous pages --- is IN the
page cache.
The main reason SHM needs its own swap code is that normal anonymous
pages are referred to only from ptes --- the ptes either point to
the physical page containing the page, or to the swap entry. We
cannot use that for SHM, because SysV SHM segments must be persistent
even if there are no attachers, and hence no ptes to maintain the
location of the pages.
If it wasn't for persistent SHM segments, it would be trivial to
integrate SHM into the normal swapper.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 13:04 ` Christoph Rohland
@ 2000-06-07 13:39 ` Rik van Riel
2000-06-07 14:29 ` Christoph Rohland
0 siblings, 1 reply; 21+ messages in thread
From: Rik van Riel @ 2000-06-07 13:39 UTC (permalink / raw)
To: Christoph Rohland; +Cc: linux-mm
On 7 Jun 2000, Christoph Rohland wrote:
> Rik van Riel <riel@conectiva.com.br> writes:
> > Ahh, but it could easily swap them out when the last of the
> > pages is unmapped.
> >
> > if (PageSHM(page) && not_in_use(page) && PageDirty(page)) {
> > swapentry_t entry;
> > entry.val = alloc_swap_entry();
> > ....
> > rw_swap_page(page);
> > }
> >
> > And the next time it can be freed like a normal SwapCache
> > page...
>
> O.K. So what do I test in PageSHM()? Right now there is no such flag.
It's just another flag for page->flags usage. When we allocate
the SHM page (shm_nopage??), we simply mark the page as such.
The SetPage<foo>(page) macros in include/linux/mm.h can be used
for this.
> > > Thus shm does it's own page handling and swap out mechanism.
> > > Since I do not know enough about the page cache I will not do
> > > this before 2.5. If you think it can be easily done, feel free
> > > to do it yourself or show me the way to go (But I will be on
> > > vacation the next two weeks).
> >
> > OK. The shrink_mmap() side of the story should be relatively
> > easy (see above), but the ipc/shm.c part is a complete mystery
> > to me ... ;(
>
> You see and for me it's vice versa. The shm part is relatively
> easy. Pages in shm do not get introduced into any other cache
> unless they are swapped out. shm uses a very dumb algorithm to
> find swappable pages when shm_swap is called.
The only thing we really want to change is the algorithm to
find which pages to swap. If we can put the shm pages on the
normal LRU queue, we'll be finding better pages to swap out
and performance (and robustness) under load will be better.
> If we want to introduce the shm pages into the lru lists, we
> need a mark as shm page. Then we could perhaps make shm_swap
> obsolete and leave the work to shrink_mmap. But shrink_mmap is
> new to me...
Basically we need 2 things from the shm code, then I'll
be able to adapt shrink_mmap with a few minutes of work ;)
1) shm pages should be marked as such so we can recognise them
2) we need to be able to swap out shm pages (maybe just
call a page->mapping->swapout() function?) by knowing just
the page
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 13:32 ` [PATCH] VM kswapd autotuning vs. -ac7 Stephen C. Tweedie
@ 2000-06-07 14:09 ` Jamie Lokier
2000-06-07 14:11 ` Christoph Rohland
1 sibling, 0 replies; 21+ messages in thread
From: Jamie Lokier @ 2000-06-07 14:09 UTC (permalink / raw)
To: Stephen C. Tweedie; +Cc: Christoph Rohland, Rik van Riel, linux-mm
Stephen C. Tweedie wrote:
> The main reason SHM needs its own swap code is that normal anonymous
> pages are referred to only from ptes --- the ptes either point to
> the physical page containing the page, or to the swap entry. We
> cannot use that for SHM, because SysV SHM segments must be persistent
> even if there are no attachers, and hence no ptes to maintain the
> location of the pages.
It might be possible to create MMs without tasks specifically to map the
SHM segments.
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 13:32 ` [PATCH] VM kswapd autotuning vs. -ac7 Stephen C. Tweedie
2000-06-07 14:09 ` Jamie Lokier
@ 2000-06-07 14:11 ` Christoph Rohland
2000-06-07 14:17 ` Stephen C. Tweedie
1 sibling, 1 reply; 21+ messages in thread
From: Christoph Rohland @ 2000-06-07 14:11 UTC (permalink / raw)
To: Stephen C. Tweedie; +Cc: Rik van Riel, linux-mm
Hi Steven,
"Stephen C. Tweedie" <sct@redhat.com> writes:
> The swap cache --- which does handle anonymous pages --- is IN the
> page cache.
>
> The main reason SHM needs its own swap code is that normal anonymous
> pages are referred to only from ptes --- the ptes either point to
> the physical page containing the page, or to the swap entry. We
> cannot use that for SHM, because SysV SHM segments must be persistent
> even if there are no attachers, and hence no ptes to maintain the
> location of the pages.
>
> If it wasn't for persistent SHM segments, it would be trivial to
> integrate SHM into the normal swapper.
But for persistence we now have the shm dentries (We will have at
least. I am planning to reuse the ramfs directory handling for shm
fs. This locks the dentries into the cache for persistence).
Couldn't we use this to get the desired behaviour?
Just guessing
Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 14:11 ` Christoph Rohland
@ 2000-06-07 14:17 ` Stephen C. Tweedie
0 siblings, 0 replies; 21+ messages in thread
From: Stephen C. Tweedie @ 2000-06-07 14:17 UTC (permalink / raw)
To: Christoph Rohland; +Cc: Stephen C. Tweedie, Rik van Riel, linux-mm
Hi,
On Wed, Jun 07, 2000 at 04:11:20PM +0200, Christoph Rohland wrote:
>
> But for persistence we now have the shm dentries (We will have at
> least. I am planning to reuse the ramfs directory handling for shm
> fs. This locks the dentries into the cache for persistence).
>
> Couldn't we use this to get the desired behaviour?
No, the dentries make things neat for the VFS but they don't help
the VM at all.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 13:39 ` Rik van Riel
@ 2000-06-07 14:29 ` Christoph Rohland
2000-06-07 14:43 ` Stephen C. Tweedie
0 siblings, 1 reply; 21+ messages in thread
From: Christoph Rohland @ 2000-06-07 14:29 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-mm
Rik van Riel <riel@conectiva.com.br> writes:
> Basically we need 2 things from the shm code, then I'll
> be able to adapt shrink_mmap with a few minutes of work ;)
>
> 1) shm pages should be marked as such so we can recognise them
O.K. this is trivial.
> 2) we need to be able to swap out shm pages (maybe just
> call a page->mapping->swapout() function?) by knowing just
> the page
This is not that easy. I need a backreference to the shm segment and
the index into it to be able to note the new pte entry. Do you know
where we could put these?
Greetings
Christoph
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] VM kswapd autotuning vs. -ac7
2000-06-07 14:29 ` Christoph Rohland
@ 2000-06-07 14:43 ` Stephen C. Tweedie
2000-06-08 15:04 ` [PATCH,incomplete] shm integration into shrink_mmap Christoph Rohland
0 siblings, 1 reply; 21+ messages in thread
From: Stephen C. Tweedie @ 2000-06-07 14:43 UTC (permalink / raw)
To: Christoph Rohland; +Cc: Rik van Riel, linux-mm
Hi,
On Wed, Jun 07, 2000 at 04:29:15PM +0200, Christoph Rohland wrote:
> > 2) we need to be able to swap out shm pages (maybe just
> > call a page->mapping->swapout() function?) by knowing just
> > the page
>
> This is not that easy. I need a backreference to the shm segment and
> the index into it to be able to note the new pte entry. Do you know
> where we could put these?
It's also trivial: just maintain a struct address_space for each
shm segment, and put the shm segment address in the address_space->
host field. Index each shm page against that address_space and
the VM will be able to find you for any callbacks it needs to make,
and you will be able to find the shm segment from that.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH,incomplete] shm integration into shrink_mmap
2000-06-07 14:43 ` Stephen C. Tweedie
@ 2000-06-08 15:04 ` Christoph Rohland
2000-06-08 15:21 ` Juan J. Quintela
2000-06-08 15:35 ` Rik van Riel
0 siblings, 2 replies; 21+ messages in thread
From: Christoph Rohland @ 2000-06-08 15:04 UTC (permalink / raw)
To: Rik van Riel; +Cc: Stephen C. Tweedie, linux-mm
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
Hi Rik,
Here is my first proposal for changing shm to be integrated into
shrink_mmap.
It gives you a function 'int shm_write_swap (struct page *page)' to
write out a page to swap and replace the pte in the shm structures. I
tested the stuff with no swapping and it seems stable so far. But
shm_write_swap is completely untested.
It probably needs to add the pages in shm_nopage_core to your lru
queues and of course it needs the calls from shrink_mmap.
I think it would be nicer to only have a notify function instead of
shm_write_swap, which gets the page and the swap_entry and can simply
put the swap_entry into the shm structures without handling the
swapping at all.
What do you think?
Christoph
[-- Attachment #2: patch-shm_shrink_mmap --]
[-- Type: text/plain, Size: 8385 bytes --]
diff -uNr 4-1-ac10/include/linux/mm.h c/include/linux/mm.h
--- 4-1-ac10/include/linux/mm.h Wed Jun 7 11:47:52 2000
+++ c/include/linux/mm.h Thu Jun 8 10:20:52 2000
@@ -176,6 +176,7 @@
#define PG_skip 10
#define PG_unused_03 11
#define PG_highmem 12
+#define PG_shm 13
/* bits 21-30 unused */
#define PG_reserved 31
@@ -220,6 +221,9 @@
#define PageClearSwapCache(page) clear_bit(PG_swap_cache, &(page)->flags)
#define PageTestandClearSwapCache(page) test_and_clear_bit(PG_swap_cache, &(page)->flags)
+
+#define PageSHM(page) test_bit(PG_shm, &(page)->flags)
+#define SetPageSHM(page) set_bit(PG_shm, &(page)->flags)
#ifdef CONFIG_HIGHMEM
#define PageHighMem(page) test_bit(PG_highmem, &(page)->flags)
diff -uNr 4-1-ac10/ipc/shm.c c/ipc/shm.c
--- 4-1-ac10/ipc/shm.c Wed Jun 7 11:43:52 2000
+++ c/ipc/shm.c Thu Jun 8 15:12:00 2000
@@ -81,6 +81,7 @@
unsigned long shm_npages; /* size of segment (pages) */
pte_t **shm_dir; /* ptr to arr of ptrs to frames */
int id;
+ struct address_space mapping;
union permap {
struct shmem {
time_t atime;
@@ -130,7 +131,6 @@
static int sysvipc_shm_read_proc(char *buffer, char **start, off_t offset, int length, int *eof, void *data);
#endif
-static void zshm_swap (int prio, int gfp_mask);
static void zmap_unuse(swp_entry_t entry, struct page *page);
static void shmzero_open(struct vm_area_struct *shmd);
static void shmzero_close(struct vm_area_struct *shmd);
@@ -628,7 +628,9 @@
if (pte_none(pte))
continue;
if (pte_present(pte)) {
- __free_page (pte_page(pte));
+ struct page *page = pte_page(pte);
+ page->mapping = NULL; /* make __free_pages_ok happy */
+ __free_page (page);
rss++;
} else {
swap_free(pte_to_swp_entry(pte));
@@ -744,6 +746,12 @@
shp->shm_npages = numpages;
shp->shm_nattch = 0;
shp->shm_namelen = namelen;
+ INIT_LIST_HEAD (&shp->mapping.pages);
+ shp->mapping.nrpages = 0;
+ shp->mapping.a_ops = NULL;
+ shp->mapping.host = (void *) shp;
+ shp->mapping.i_mmap = NULL;
+ spin_lock_init(&shp->mapping.i_shared_lock);
return(shp);
}
@@ -1441,6 +1449,9 @@
(*swp)--;
}
(*rss)++;
+ SetPageSHM(page);
+ page->mapping = &shp->mapping;
+ page->index = idx;
pte = pte_mkdirty(mk_pte(page, PAGE_SHARED));
SHM_ENTRY(shp, idx) = pte;
}
@@ -1473,124 +1484,55 @@
return(page);
}
-#define OKAY 0
-#define RETRY 1
-#define FAILED 2
-
-static int shm_swap_core(struct shmid_kernel *shp, unsigned long idx, swp_entry_t swap_entry, int *counter, struct page **outpage)
-{
- pte_t page;
- struct page *page_map;
-
- page = SHM_ENTRY(shp, idx);
- if (!pte_present(page))
- return RETRY;
- page_map = pte_page(page);
- if (page_map->zone->free_pages > page_map->zone->pages_high)
- return RETRY;
- if (shp->id != zero_id) swap_attempts++;
-
- if (--counter < 0) /* failed */
- return FAILED;
- if (page_count(page_map) != 1)
- return RETRY;
-
- lock_page(page_map);
- if (!(page_map = prepare_highmem_swapout(page_map)))
- return FAILED;
- SHM_ENTRY (shp, idx) = swp_entry_to_pte(swap_entry);
-
- /* add the locked page to the swap cache before allowing
- the swapin path to run lookup_swap_cache(). This avoids
- reading a not yet uptodate block from disk.
- NOTE: we just accounted the swap space reference for this
- swap cache page at __get_swap_page() time. */
- add_to_swap_cache(*outpage = page_map, swap_entry);
- return OKAY;
-}
-
-static void shm_swap_postop(struct page *page)
+int shm_write_swap (struct page *page)
{
- lock_kernel();
- rw_swap_page(WRITE, page, 0);
- unlock_kernel();
- page_cache_release(page);
-}
+ struct shmid_kernel *shp;
+ swp_entry_t swap_entry;
+ unsigned long idx;
+
+ if (!PageSHM (page))
+ BUG();
-static int shm_swap_preop(swp_entry_t *swap_entry)
-{
lock_kernel();
/* subtle: preload the swap count for the swap cache. We can't
increase the count inside the critical section as we can't release
the shm_lock there. And we can't acquire the big lock with the
shm_lock held (otherwise we would deadlock too easily). */
- *swap_entry = __get_swap_page(2);
- if (!(*swap_entry).val) {
+ swap_entry = __get_swap_page(2);
+ if (!swap_entry.val) {
unlock_kernel();
- return 1;
+ return 0;
}
unlock_kernel();
- return 0;
-}
-
-/*
- * Goes through counter = (shm_rss / (prio + 1)) present shm pages.
- */
-static unsigned long swap_id; /* currently being swapped */
-static unsigned long swap_idx; /* next to swap */
-int shm_swap (int prio, int gfp_mask)
-{
- struct shmid_kernel *shp;
- swp_entry_t swap_entry;
- unsigned long id, idx;
- int loop = 0;
- int counter;
- struct page * page_map;
-
- zshm_swap(prio, gfp_mask);
- counter = shm_rss / (prio + 1);
- if (!counter)
- return 0;
- if (shm_swap_preop(&swap_entry))
- return 0;
+ shp = (struct shmid_kernel *) page->mapping->host;
+ idx = page->index;
+ if (shp->id != zero_id) swap_attempts++;
+ lock_page(page);
+ if (!(page = prepare_highmem_swapout(page)))
+ goto err;
shm_lockall();
-check_id:
- shp = shm_get(swap_id);
- if(shp==NULL || shp->shm_flags & PRV_LOCKED) {
-next_id:
- swap_idx = 0;
- if (++swap_id > shm_ids.max_id) {
- swap_id = 0;
- if (loop) {
-failed:
- shm_unlockall();
- __swap_free(swap_entry, 2);
- return 0;
- }
- loop = 1;
- }
- goto check_id;
- }
- id = swap_id;
-
-check_table:
- idx = swap_idx++;
- if (idx >= shp->shm_npages)
- goto next_id;
-
- switch (shm_swap_core(shp, idx, swap_entry, &counter, &page_map)) {
- case RETRY: goto check_table;
- case FAILED: goto failed;
- }
+ SHM_ENTRY (shp, idx) = swp_entry_to_pte(swap_entry);
swap_successes++;
shm_swp++;
shm_rss--;
shm_unlockall();
- shm_swap_postop(page_map);
+ /* add the locked page to the swap cache before allowing
+ the swapin path to run lookup_swap_cache(). This avoids
+ reading a not yet uptodate block from disk.
+ NOTE: we just accounted the swap space reference for this
+ swap cache page at __get_swap_page() time. */
+ add_to_swap_cache(page, swap_entry);
+ lock_kernel();
+ rw_swap_page(WRITE, page, 0);
+ unlock_kernel();
+ page_cache_release(page);
return 1;
+err:
+ __swap_free(swap_entry, 2);
+ return 0;
}
/*
@@ -1718,7 +1660,6 @@
#define VMA_TO_SHP(vma) ((vma)->vm_file->private_data)
static spinlock_t zmap_list_lock = SPIN_LOCK_UNLOCKED;
-static unsigned long zswap_idx; /* next to swap */
static struct shmid_kernel *zswap_shp = &zshmid_kernel;
static int zshm_rss;
@@ -1864,63 +1805,5 @@
}
shm_unlock(zero_id);
spin_unlock(&zmap_list_lock);
-}
-
-static void zshm_swap (int prio, int gfp_mask)
-{
- struct shmid_kernel *shp;
- swp_entry_t swap_entry;
- unsigned long idx;
- int loop = 0;
- int counter;
- struct page * page_map;
-
- counter = zshm_rss / (prio + 1);
- if (!counter)
- return;
-next:
- if (shm_swap_preop(&swap_entry))
- return;
-
- spin_lock(&zmap_list_lock);
- shm_lock(zero_id);
- if (zshmid_kernel.zero_list.next == 0)
- goto failed;
-next_id:
- if (zswap_shp == &zshmid_kernel) {
- if (loop) {
-failed:
- shm_unlock(zero_id);
- spin_unlock(&zmap_list_lock);
- __swap_free(swap_entry, 2);
- return;
- }
- zswap_shp = list_entry(zshmid_kernel.zero_list.next,
- struct shmid_kernel, zero_list);
- zswap_idx = 0;
- loop = 1;
- }
- shp = zswap_shp;
-
-check_table:
- idx = zswap_idx++;
- if (idx >= shp->shm_npages) {
- zswap_shp = list_entry(zswap_shp->zero_list.next,
- struct shmid_kernel, zero_list);
- zswap_idx = 0;
- goto next_id;
- }
-
- switch (shm_swap_core(shp, idx, swap_entry, &counter, &page_map)) {
- case RETRY: goto check_table;
- case FAILED: goto failed;
- }
- shm_unlock(zero_id);
- spin_unlock(&zmap_list_lock);
-
- shm_swap_postop(page_map);
- if (counter)
- goto next;
- return;
}
diff -uNr 4-1-ac10/ipc/util.c c/ipc/util.c
--- 4-1-ac10/ipc/util.c Mon Jun 5 11:12:29 2000
+++ c/ipc/util.c Thu Jun 8 13:27:27 2000
@@ -243,11 +243,6 @@
return;
}
-int shm_swap (int prio, int gfp_mask)
-{
- return 0;
-}
-
asmlinkage long sys_semget (key_t key, int nsems, int semflg)
{
return -ENOSYS;
diff -uNr 4-1-ac10/mm/vmscan.c c/mm/vmscan.c
--- 4-1-ac10/mm/vmscan.c Mon Jun 5 11:12:29 2000
+++ c/mm/vmscan.c Thu Jun 8 13:28:17 2000
@@ -471,11 +471,6 @@
ret = 1;
goto done;
}
- while (shm_swap(priority, gfp_mask)) {
- ret = 1;
- if (!--count)
- goto done;
- }
}
/*
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH,incomplete] shm integration into shrink_mmap
2000-06-08 15:04 ` [PATCH,incomplete] shm integration into shrink_mmap Christoph Rohland
@ 2000-06-08 15:21 ` Juan J. Quintela
2000-06-08 15:35 ` Rik van Riel
1 sibling, 0 replies; 21+ messages in thread
From: Juan J. Quintela @ 2000-06-08 15:21 UTC (permalink / raw)
To: Christoph Rohland; +Cc: Rik van Riel, Stephen C. Tweedie, linux-mm
>>>>> "christoph" == Christoph Rohland <cr@sap.com> writes:
Hi christoph
christoph> Here is my first proposal for changing shm to be integrated into
christoph> shrink_mmap.
christoph> It gives you a function 'int shm_write_swap (struct page *page)' to
christoph> write out a page to swap and replace the pte in the shm structures. I
christoph> tested the stuff with no swapping and it seems stable so far. But
christoph> shm_write_swap is completely untested.
christoph> It probably needs to add the pages in shm_nopage_core to your lru
christoph> queues and of course it needs the calls from shrink_mmap.
christoph> I think it would be nicer to only have a notify function instead of
christoph> shm_write_swap, which gets the page and the swap_entry and can simply
christoph> put the swap_entry into the shm structures without handling the
christoph> swapping at all.
christoph> What do you think?
christoph> Christoph
It lacks the cleanup of the SHM page bit :)))
But it looks great so far. I am working just now it the shrink_mmap
integration.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH,incomplete] shm integration into shrink_mmap
2000-06-08 15:04 ` [PATCH,incomplete] shm integration into shrink_mmap Christoph Rohland
2000-06-08 15:21 ` Juan J. Quintela
@ 2000-06-08 15:35 ` Rik van Riel
1 sibling, 0 replies; 21+ messages in thread
From: Rik van Riel @ 2000-06-08 15:35 UTC (permalink / raw)
To: Christoph Rohland; +Cc: linux-mm
On 8 Jun 2000, Christoph Rohland wrote:
> Here is my first proposal for changing shm to be integrated into
> shrink_mmap.
>
> It gives you a function 'int shm_write_swap (struct page *page)'
> to write out a page to swap and replace the pte in the shm
> structures.
> What do you think?
This is a great start. We probably want to make the
shm_write_swap() function a function pointer in the
page->mapping struct so the shrink_mmap() code can
call the same function for every page, but other than
that this is the direction I'd like VM to go.
I've seen Juan Quintela is already looking into your
patch trying to write the missing part, so I guess
I'll continue on the active/inactive/scavenge list
code and not look at your patch in detail today ;)
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2000-06-08 15:35 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-01 22:31 [PATCH] VM kswapd autotuning vs. -ac7 Rik van Riel
2000-06-02 15:54 ` Christoph Rohland
2000-06-02 16:01 ` Rik van Riel
2000-06-03 9:02 ` Christoph Rohland
2000-06-03 20:47 ` Rik van Riel
2000-06-04 11:12 ` Christoph Rohland
2000-06-05 8:58 ` Christoph Rohland
2000-06-05 10:16 ` Rik van Riel
2000-06-07 10:23 ` Christoph Rohland
2000-06-07 12:43 ` Rik van Riel
2000-06-07 13:04 ` Christoph Rohland
2000-06-07 13:39 ` Rik van Riel
2000-06-07 14:29 ` Christoph Rohland
2000-06-07 14:43 ` Stephen C. Tweedie
2000-06-08 15:04 ` [PATCH,incomplete] shm integration into shrink_mmap Christoph Rohland
2000-06-08 15:21 ` Juan J. Quintela
2000-06-08 15:35 ` Rik van Riel
2000-06-07 13:32 ` [PATCH] VM kswapd autotuning vs. -ac7 Stephen C. Tweedie
2000-06-07 14:09 ` Jamie Lokier
2000-06-07 14:11 ` Christoph Rohland
2000-06-07 14:17 ` Stephen C. Tweedie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox