I had sent this patch a few hours ago but didn't see it on the list...
Anyway, there was a mistake in the diff I sent so there you go a new
version.
I've merged the incremental diffs of rmap (rmap14c-rmap15 and
rmap15-rmapa) with 2.4.20-ac1
There was no inconsistency but in three spots.
Namely:
...from the original rmap...
diff -Nru a/mm/shmem.c b/mm/shmem.c
--- a/mm/shmem.c Mon Nov 18 10:28:28 2002
+++ b/mm/shmem.c Mon Nov 18 10:28:28 2002
@@ -557,7 +557,7 @@
unsigned long flags;
/* Look it up and read it in.. */
- page = find_get_page(&swapper_space, entry->val);
+ page = find_pagecache_page(&swapper_space, entry->val);
if (!page) {
swp_entry_t swap = *entry;
spin_unlock (&info->lock);
...to how I left it...
diff -purN linux-2.4.20-ac1/mm/shmem.c linux-2.4.20-ac1-rmap15a/mm/shmem.c
--- linux-2.4.20-ac1/mm/shmem.c 2002-12-01 11:01:04.000000000 +0100
+++ linux-2.4.20-ac1-rmap15a/mm/shmem.c 2002-12-01 10:43:15.000000000 +0100
@@ -593,7 +593,7 @@ repeat:
unsigned long flags;
/* Look it up and read it in.. */
- page = lookup_swap_cache(*entry);
+ page = find_pagecache_page(&swapper_space, entry->val);
if (!page) {
swp_entry_t swap = *entry;
spin_unlock (&info->lock);
I didn't know which version to leave, rmap's or original ac's
Then, this enum was different in -ac than stock, thus I didn't feel too
well when mixing it...
diff -Nru a/include/linux/brlock.h b/include/linux/brlock.h
--- a/include/linux/brlock.h Mon Nov 18 10:28:28 2002
+++ b/include/linux/brlock.h Mon Nov 18 10:28:28 2002
@@ -34,6 +34,7 @@
enum brlock_indices {
BR_GLOBALIRQ_LOCK,
BR_NETPROTO_LOCK,
+ BR_LRU_LOCK,
__BR_END
};
diff -purN linux-2.4.20-ac1/include/linux/brlock.h linux-2.4.20-ac1-rmap15a/include/linux/brlock.h
--- linux-2.4.20-ac1/include/linux/brlock.h 2002-12-01 11:01:04.000000000 +0100
+++ linux-2.4.20-ac1-rmap15a/include/linux/brlock.h 2002-12-01 10:43:15.000000000 +0100
@@ -37,6 +37,7 @@ enum brlock_indices {
BR_GLOBALIRQ_LOCK,
BR_NETPROTO_LOCK,
BR_LLC_LOCK,
+ BR_LRU_LOCK,
__BR_END
};
And last, on this one, the wmb() call is not present on -ac. Everything
else was the same.
diff -Nru a/mm/vmscan.c b/mm/vmscan.c
--- a/mm/vmscan.c Mon Nov 18 10:28:28 2002
+++ b/mm/vmscan.c Mon Nov 18 10:28:28 2002
@@ -846,7 +961,7 @@
/* OK, the VM is very loaded. Sleep instead of using all CPU. */
kswapd_overloaded = 1;
set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(HZ / 4);
+ schedule_timeout(HZ / 40);
kswapd_overloaded = 0;
wmb();
return;
Feel free to try it. I'm running it right now and so far no problems.
The vm usage has definitely improved, but there are still slight stalls
when there's a high disk io. Say, in periods of ~2-3s the system stopped
responding for a few cents of a sec, as if it had tachycardia.
--
Javier Marcet <[email protected]>
On Mon, 2 Dec 2002, Javier Marcet wrote:
> There was no inconsistency but in three spots.
Your changes look good. Maybe the lookup_swapcache() thing would
be more beautiful, but it's equivalent to the code you've got in
place. Your patch should just work.
> Feel free to try it. I'm running it right now and so far no problems.
> The vm usage has definitely improved, but there are still slight stalls
> when there's a high disk io. Say, in periods of ~2-3s the system stopped
> responding for a few cents of a sec, as if it had tachycardia.
That's probably the disk IO scheduler.
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
* Rik van Riel <[email protected]> [021202 13:52]:
>>There was no inconsistency but in three spots.
>Your changes look good. Maybe the lookup_swapcache() thing would
>be more beautiful, but it's equivalent to the code you've got in
>place. Your patch should just work.
There are a couple issues, e.g. in mm/filemap.c, in the patchset I sent.
I'll be looking into it today. I hope to send something within a few
hours. But since tomorrow morning I'm moving, and I'm now packaging et
all, I might have no time to finish it today. In that case until
Wednesday I don't think I'll be able to continue on it...
>>Feel free to try it. I'm running it right now and so far no problems.
>>The vm usage has definitely improved, but there are still slight stalls
>>when there's a high disk io. Say, in periods of ~2-3s the system stopped
>>responding for a few cents of a sec, as if it had tachycardia.
>That's probably the disk IO scheduler.
Yeah, definitely. I'm following the other thread on 2.4.20-rmap15a and
the dl hack. Let's see if we -you really, I'm not yet contributing
anything- can make 2.4.20 work smoothly.
--
Javier Marcet <[email protected]>
On Mon, 2 Dec 2002, Javier Marcet wrote:
> I had sent this patch a few hours ago but didn't see it on the list...
> Anyway, there was a mistake in the diff I sent so there you go a new
> version.
> I've merged the incremental diffs of rmap (rmap14c-rmap15 and
> rmap15-rmapa) with 2.4.20-ac1
> There was no inconsistency but in three spots.
> Namely:
>
> ...from the original rmap...
> diff -Nru a/mm/shmem.c b/mm/shmem.c
> --- a/mm/shmem.c Mon Nov 18 10:28:28 2002
> +++ b/mm/shmem.c Mon Nov 18 10:28:28 2002
> @@ -557,7 +557,7 @@
> unsigned long flags;
>
> /* Look it up and read it in.. */
> - page = find_get_page(&swapper_space, entry->val);
> + page = find_pagecache_page(&swapper_space, entry->val);
> if (!page) {
> swp_entry_t swap = *entry;
> spin_unlock (&info->lock);
>
> ...to how I left it...
> diff -purN linux-2.4.20-ac1/mm/shmem.c linux-2.4.20-ac1-rmap15a/mm/shmem.c
> --- linux-2.4.20-ac1/mm/shmem.c 2002-12-01 11:01:04.000000000 +0100
> +++ linux-2.4.20-ac1-rmap15a/mm/shmem.c 2002-12-01 10:43:15.000000000 +0100
> @@ -593,7 +593,7 @@ repeat:
> unsigned long flags;
>
> /* Look it up and read it in.. */
> - page = lookup_swap_cache(*entry);
> + page = find_pagecache_page(&swapper_space, entry->val);
> if (!page) {
> swp_entry_t swap = *entry;
> spin_unlock (&info->lock);
>
> I didn't know which version to leave, rmap's or original ac's
It doesn't matter a great deal, but leaving it as lookup_swap_cache
would be correct - the difference lies solely in the swap cache "find"
statistics shown by AltSysRqM, which find_get_page shortcircuited
(whereas "add" and "delete" were getting updated for mm/shmem.c).
lookup_swap_cache is itself patched to say find_pagecache_page instead
of find_get_page - though why an -rmap patch should be changing that
well-established name escapes me: makes maintenance more tiresome.
Hugh