Re: [PATCH] fix for VM test9-pre7
Rik van Riel <[EMAIL PROTECTED]> writes: > On 2 Oct 2000, Christoph Rohland wrote: > > > the shm swapping still kills the machine(8GB mem) the machine > > with somthing like '__alloc_pages failed order 0'. > > > > When I do the same stresstest with mmaped file in ext2 the > > machine runs fine but the processes do not do anything and > > vmstat/ps lock up on these processes. > > This may be a highmem bounce-buffer creation deadlock. Do > your tests work if you use only 800 MB of RAM ? > > Shared memory swapping on my 64 MB test machine seems to > work fine (albeit a bit slow). Yupp, with mem=850M it seems to work. Greetings Christoph -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
On 2 Oct 2000, Christoph Rohland wrote: > the shm swapping still kills the machine(8GB mem) the machine > with somthing like '__alloc_pages failed order 0'. > > When I do the same stresstest with mmaped file in ext2 the > machine runs fine but the processes do not do anything and > vmstat/ps lock up on these processes. This may be a highmem bounce-buffer creation deadlock. Do your tests work if you use only 800 MB of RAM ? Shared memory swapping on my 64 MB test machine seems to work fine (albeit a bit slow). regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
Hi Rik, the shm swapping still kills the machine(8GB mem) the machine with somthing like '__alloc_pages failed order 0'. When I do the same stresstest with mmaped file in ext2 the machine runs fine but the processes do not do anything and vmstat/ps lock up on these processes. Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
On Mon, 2 Oct 2000 [EMAIL PROTECTED] wrote:
> On Mon, Oct 02, 2000 at 12:42:47AM -0300, Rik van Riel wrote:
> > --- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
> > +++ linux-2.4.0-test9-pre7/fs/buffer.c Mon Oct 2 00:19:41 2000
> > @@ -706,7 +706,9 @@
> > static void refill_freelist(int size)
> > {
> > if (!grow_buffers(size)) {
> > - try_to_free_pages(GFP_BUFFER);
> > + wakeup_bdflush(1);
> > + current->policy |= SCHED_YIELD;
> > + schedule();
> > }
> > }
>
> This part looks strange! wakeup_bdflush will sleep if the
> parameter is not zero, i.e. we'll schedule twice. I doubt that
> this the intended behaviour?
Heh...
I copied back the old code because I saw some failures in
the try_to_free_pages() in this situation.
Maybe the person who wrote this code originally can comment
on this one ?
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
Hi,
On Mon, Oct 02, 2000 at 12:42:47AM -0300, Rik van Riel wrote:
> --- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
> +++ linux-2.4.0-test9-pre7/fs/buffer.cMon Oct 2 00:19:41 2000
> @@ -706,7 +706,9 @@
> static void refill_freelist(int size)
> {
> if (!grow_buffers(size)) {
> - try_to_free_pages(GFP_BUFFER);
> + wakeup_bdflush(1);
> + current->policy |= SCHED_YIELD;
> + schedule();
> }
> }
This part looks strange! wakeup_bdflush will sleep if the parameter
is not zero, i.e. we'll schedule twice. I doubt that this the intended
behaviour?
regardsChristian
--
THAT'S ALL FOLKS!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix for VM test9-pre7
Hi,
The attached patch seems to fix all the reported deadlock
problems with the new VM. Basically they could be grouped
into 2 categories:
1) __GFP_IO related locking issues
2) something sleeps on a free/clean/inactive page goal
that isn't worked towards
The patch has survived some heavy stresstesting on both
SMP and UP machines. I hope nobody will be able to find
a way to still crash this one ;)
A second change is a more dynamic free memory target
(now freepages.high + inactive_target / 3), this seems
to help a little bit in some loads.
If your mailer messes up the patch, you can grab it from
http://www.surriel.com/patches/2.4.0-t9p7-vmpatch
Linus, if this patch turns out to work fine for the people
testing it, could you please apply it to your tree?
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
--- linux-2.4.0-test9-pre7/fs/buffer.c.orig Sat Sep 30 18:09:18 2000
+++ linux-2.4.0-test9-pre7/fs/buffer.c Mon Oct 2 00:19:41 2000
@@ -706,7 +706,9 @@
static void refill_freelist(int size)
{
if (!grow_buffers(size)) {
- try_to_free_pages(GFP_BUFFER);
+ wakeup_bdflush(1);
+ current->policy |= SCHED_YIELD;
+ schedule();
}
}
@@ -859,6 +861,7 @@
int balance_dirty_state(kdev_t dev)
{
unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
+ int shortage;
dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
tot = nr_free_buffer_pages();
@@ -869,21 +872,20 @@
/* First, check for the "real" dirty limit. */
if (dirty > soft_dirty_limit) {
- if (dirty > hard_dirty_limit || inactive_shortage())
+ if (dirty > hard_dirty_limit)
return 1;
return 0;
}
/*
-* Then, make sure the number of inactive pages won't overwhelm
-* page replacement ... this should avoid stalls.
+* If we are about to get low on free pages and
+* cleaning the inactive_dirty pages would help
+* fix this, wake up bdflush.
*/
- if (nr_inactive_dirty_pages >
- nr_free_pages() + nr_inactive_clean_pages()) {
- if (free_shortage() > freepages.min)
- return 1;
+ if (free_shortage() && nr_inactive_dirty_pages > free_shortage() &&
+ nr_inactive_dirty_pages > freepages.high)
return 0;
- }
+
return -1;
}
@@ -2663,9 +2665,8 @@
CHECK_EMERGENCY_SYNC
flushed = flush_dirty_buffers(0);
- if (nr_inactive_dirty_pages > nr_free_pages() +
- nr_inactive_clean_pages())
- flushed += page_launder(GFP_KSWAPD, 0);
+ if (free_shortage())
+ flushed += page_launder(GFP_BUFFER, 0);
/* If wakeup_bdflush will wakeup us
after our bdflush_done wakeup, then
--- linux-2.4.0-test9-pre7/mm/filemap.c.origSat Sep 30 18:16:28 2000
+++ linux-2.4.0-test9-pre7/mm/filemap.c Mon Oct 2 00:11:45 2000
@@ -44,7 +44,6 @@
atomic_t page_cache_size = ATOMIC_INIT(0);
unsigned int page_hash_bits;
struct page **page_hash_table;
-struct list_head lru_cache;
spinlock_t pagecache_lock = SPIN_LOCK_UNLOCKED;
/*
--- linux-2.4.0-test9-pre7/mm/page_alloc.c.orig Sat Sep 30 18:16:28 2000
+++ linux-2.4.0-test9-pre7/mm/page_alloc.c Mon Oct 2 00:31:15 2000
@@ -258,13 +258,13 @@
*/
switch (limit) {
default:
- case 0:
+ case PAGES_MIN:
water_mark = z->pages_min;
break;
- case 1:
+ case PAGES_LOW:
water_mark = z->pages_low;
break;
- case 2:
+ case PAGES_HIGH:
water_mark = z->pages_high;
}
@@ -318,10 +318,19 @@
direct_reclaim = 1;
/*
-* Are we low on inactive pages?
+* If we are about to get low on free pages and we also have
+* an inactive page shortage, wake up kswapd.
*/
if (inactive_shortage() > inactive_target / 2 && free_shortage())
wakeup_kswapd(0);
+ /*
+* If we are about to get low on free pages and cleaning
+* the inactive_dirty pages would fix the situation,
+* wake up bdflush.
+*/
+ else if (free_shortage() && nr_inactive_dirty_pages > free_shortage()
+ && nr_inactive_dirty_pages > freepages.high)
+ wakeup_bdflush(0);
try_again:
/*
@@ -378,8 +387,23 @
