linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: Oops in __free_pages_ok (pre7-1) (Long)
@ 2000-05-02  1:08 Juan J. Quintela
  2000-05-02 20:43 ` Linus Torvalds
  2000-05-02 22:08 ` Andrea Arcangeli
  0 siblings, 2 replies; 16+ messages in thread
From: Juan J. Quintela @ 2000-05-02  1:08 UTC (permalink / raw)
  To: linux-mm, Linus Torvalds, Andrea Arcangeli, Kanoj Sarcar

Hi
        several people have reported Oops in __free_pages_ok, after a
BUG() in page_alloc.h.  This happens in 2.3.99-pre[67].  The BUGs are:

	if (page->mapping)
		BUG();
and
	if (PageSwapCache(page))
		BUG();
somebody reported to me that he obtained the BUG:
	if (PageLocked(page))
		BUG();

I have found that this patch solves the Oops for me. (I know that this
is not the proper solution, could people test this patch and mail me
if the Oops disappear/or go worst?  I am trying to isolate the
problem.  Now I get one kill of the process from the VM, I am
interested to know if this is the case for the rest of the people with
this problem.

I have read the comments from Andrea in this list about that
PG_swap_entry bit should be only a optimization, never produce
instability.  I have checked that with the following patch (i.e. the
only place when we set that bit) I don't get more Oops.

This bit is only used in three places in the kernel:

mm/memory.c:1056:do_swap_page()::SetPageSwapEntry(page);
        The only place where it is set

mm/swapfile.c:210:acquire_swap_entry():	if (!PageSwapEntry(page))
        Here we check if it is set, and if true, we check that the
        values are valid.

mm/swap_state.c:134:	ClearPageSwapEntry(page);
        We clear the bit in free_page_and_swap_cache(), but I am not
        sure that it is the only place when it must be deleted.
        Comments really appreciated.

It appears that we forgot to remove some bits/values when we free a
page. It has been several patches in this list regarding the
swap_entry bit, but not agreement in which is the correct one.

I hope this help to somebody understand where is the problem, or at
least give me some hint where can be the problem.

Thanks in advance, Juan.

diff -u -urN --exclude=CVS --exclude=*~ --exclude=.#* pre7-1plus/mm/memory.c lin
ux/mm/memory.c
--- pre7-1plus/mm/memory.c      Tue Apr 25 00:46:18 2000
+++ linux/mm/memory.c   Tue May  2 00:36:13 2000
@@ -1053,7 +1053,7 @@
 
        pte = mk_pte(page, vma->vm_page_prot);
 
-       SetPageSwapEntry(page);
+       /*      SetPageSwapEntry(page);  */
 
        /*
         * Freeze the "shared"ness of the page, ie page_count + swap_count.


-- 
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02  1:08 Oops in __free_pages_ok (pre7-1) (Long) Juan J. Quintela
@ 2000-05-02 20:43 ` Linus Torvalds
  2000-05-02 21:31   ` Juan J. Quintela
  2000-05-02 22:08 ` Andrea Arcangeli
  1 sibling, 1 reply; 16+ messages in thread
From: Linus Torvalds @ 2000-05-02 20:43 UTC (permalink / raw)
  To: Juan J. Quintela; +Cc: linux-mm, Andrea Arcangeli, Kanoj Sarcar


On 2 May 2000, Juan J. Quintela wrote:
> Hi
>         several people have reported Oops in __free_pages_ok, after a
> BUG() in page_alloc.h.  This happens in 2.3.99-pre[67].  The BUGs are:

I'd like ot know what the back-trace for those reports are? 

I'm not against getting rid of the PageSwapEntry logic (it's complication
for not very much gain), but I'd like to understand this more..

		Linus

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 20:43 ` Linus Torvalds
@ 2000-05-02 21:31   ` Juan J. Quintela
  2000-05-02 21:40     ` Linus Torvalds
                       ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Juan J. Quintela @ 2000-05-02 21:31 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-mm, Andrea Arcangeli, Kanoj Sarcar

>>>>> "linus" == Linus Torvalds <torvalds@transmeta.com> writes:

Hi

>> several people have reported Oops in __free_pages_ok, after a
>> BUG() in page_alloc.h.  This happens in 2.3.99-pre[67].  The BUGs are:

linus> I'd like ot know what the back-trace for those reports are? 

I have attached two traces to this mail. I have more if you need them,
basically it always bug in the code: page_alloc.c:__free_page_ok

	if (page->buffers)
/*102*/		BUG();
	if (page->mapping)
/*104*/		BUG();

The BUG in 104 is easy to trigger. The other one is less frequent,
doesn't happen in all the tries.

<self package advertising> 
I can reproduce this BUGs easily with the mmap002 program from the
memtest-0.0.3 suite (http://carpanta.dc.fi.udc.es/~quintela/memtest/).
You need to change the #define RAMSIZE to reflect your memory size in
include file misc_lib.h and you run it in one while(true); do
./mmap002; done and in the 8th, 9th execution it Oops here also.
</self package advertising>

I have more Oops traces, if you want more of them let me know.

linus> I'm not against getting rid of the PageSwapEntry logic (it's complication
linus> for not very much gain), but I'd like to understand this more..

If you want the patch for get rid of PG_swap_entry, I can do it and send it to
you.

Later, Juan.


        kernel BUG at page_alloc.c:102!
        kernel BUG at page_alloc.c:104!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0125e0d>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000020   ebx: 00004883   ecx: 00000019   edx: 00000000
esi: c1000128   edi: 00000000   ebp: c5464d20   esp: c5fd7ed4
ds: 0018   es: 0018   ss: 0018
Process kswapd (pid: 2, stackpage=c5fd7000)
Stack: c01cb662 c01cb950 00000066 00004883 c1000128 c26ef6d8 c5464d20 00066400 
       c10eec40 c0125512 00000001 c10eec40 c0125421 4c1b7000 c26ef6d8 4c0b3000 
       4c400000 00066400 c0125664 c5f95e00 c5464d20 4c1b6000 c26ef6d8 00000004 
Call Trace: [<c01cb662>] [<c01cb950>] [<c0125512>] [<c0125421>] [<c0125664>] [<c
012572d>] [<c01258c5>] 
       [<c012599a>] [<c0125a5d>] [<c0107474>] 
Code: 0f 0b 83 c4 0c 83 7e 08 00 74 18 6a 68 68 50 b9 1c c0 68 62 
>>EIP; c0125e0d <__free_pages_ok+2d/2fc>   <=====
Trace; c01cb662 <tvecs+3462/1ade0>
Trace; c01cb950 <tvecs+3750/1ade0>
Trace; c0125512 <try_to_swap_out+1d2/204>
Trace; c0125421 <try_to_swap_out+e1/204>
Trace; c0125664 <swap_out_vma+120/1b0>
Trace; c012572d <swap_out_mm+39/64>
Trace; c01258c5 <swap_out+16d/1c0>
Trace; c012599a <do_try_to_free_pages+82/9c>
Trace; c0125a5d <kswapd+a9/12c>
Trace; c0107474 <kernel_thread+28/38>
Code;  c0125e0d <__free_pages_ok+2d/2fc>
00000000 <_EIP>:
Code;  c0125e0d <__free_pages_ok+2d/2fc>   <=====
   0:   0f 0b             ud2a      <=====
Code;  c0125e0f <__free_pages_ok+2f/2fc>
   2:   83 c4 0c          addl   $0xc,%esp
Code;  c0125e12 <__free_pages_ok+32/2fc>
   5:   83 7e 08 00       cmpl   $0x0,0x8(%esi)
Code;  c0125e16 <__free_pages_ok+36/2fc>
   9:   74 18             je     23 <_EIP+0x23> c0125e30 <__free_pages_ok+50/2fc
>
Code;  c0125e18 <__free_pages_ok+38/2fc>
   b:   6a 68             pushl  $0x68
Code;  c0125e1a <__free_pages_ok+3a/2fc>
   d:   68 50 b9 1c c0    pushl  $0xc01cb950
Code;  c0125e1f <__free_pages_ok+3f/2fc>
  12:   68 62 00 00 00    pushl  $0x62

and the second one:

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0125e29>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000020   ebx: c1000144   ecx: 0000001b   edx: c5f95e00
esi: c1000128   edi: 00000000   ebp: c4be6980   esp: c4cb9d84
ds: 0018   es: 0018   ss: 0018
Process mmap002 (pid: 389, stackpage=c4cb9000)
Stack: c01cb662 c01cb950 00000068 c1000144 c4be6800 c4be6980 c4be6980 c0206ba4 
       c0206ba4 00000286 00000023 c4be6980 c012d317 c1000144 c1000128 c4cb9df8 
       0000007f 00000001 c011e3e7 c1000128 00000020 00000006 00000005 c0204cec 
Call Trace: [<c01cb662>] [<c01cb950>] [<c012d317>] [<c011e3e7>] [<c012594b>] [<c
0125b05>] [<c01263cc>] 
       [<c01264a4>] [<c011e9f0>] [<c011ff27>] [<c011c935>] [<c011caa0>] [<c010f1
f7>] [<c011a78a>] [<c011a891>] 
       [<c0117bd3>] [<c0117b28>] [<c0117a22>] [<c010a555>] [<c010964d>] 
Code: 0f 0b 83 c4 0c 89 f6 89 f1 2b 0d 2c 49 20 c0 8d 14 cd 00 00 


>>EIP; c0125e29 <__free_pages_ok+49/2fc>   <=====
Trace; c01cb662 <tvecs+3462/1ade0>
Trace; c01cb950 <tvecs+3750/1ade0>
Trace; c012d317 <try_to_free_buffers+11b/13c>
Trace; c011e3e7 <shrink_mmap+ff/2a0>
Trace; c012594b <do_try_to_free_pages+33/9c>
Trace; c0125b05 <try_to_free_pages+25/30>
Trace; c01263cc <zone_balance_memory+5c/8c>
Trace; c01264a4 <__alloc_pages+a8/dc>
Trace; c011e9f0 <read_cluster_nonblocking+b8/140>
Trace; c011ff27 <filemap_nopage+1a7/3ac>
Trace; c011c935 <do_no_page+4d/d0>
Trace; c011caa0 <handle_mm_fault+e8/154>
Trace; c010f1f7 <do_page_fault+187/4d0>
Trace; c011a78a <update_process_times+5a/60>
Trace; c011a891 <timer_bh+cd/2b4>
Trace; c0117bd3 <bh_action+1b/5c>
Trace; c0117b28 <tasklet_hi_action+38/60>
Trace; c0117a22 <do_softirq+52/78>
Trace; c010a555 <do_IRQ+a5/b4>
Trace; c010964d <error_code+2d/40>
Code;  c0125e29 <__free_pages_ok+49/2fc>
00000000 <_EIP>:
Code;  c0125e29 <__free_pages_ok+49/2fc>   <=====
   0:   0f 0b             ud2a      <=====
Code;  c0125e2b <__free_pages_ok+4b/2fc>
   2:   83 c4 0c          addl   $0xc,%esp
Code;  c0125e2e <__free_pages_ok+4e/2fc>
   5:   89 f6             movl   %esi,%esi
Code;  c0125e30 <__free_pages_ok+50/2fc>
   7:   89 f1             movl   %esi,%ecx
Code;  c0125e32 <__free_pages_ok+52/2fc>
   9:   2b 0d 2c 49 20    subl   0xc020492c,%ecx
Code;  c0125e37 <__free_pages_ok+57/2fc>
   e:   c0 
Code;  c0125e38 <__free_pages_ok+58/2fc>
   f:   8d 14 cd 00 00    leal   0x0(,%ecx,8),%edx
Code;  c0125e3d <__free_pages_ok+5d/2fc>
  14:   00 00 







-- 
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 21:31   ` Juan J. Quintela
@ 2000-05-02 21:40     ` Linus Torvalds
  2000-05-02 22:06       ` Juan J. Quintela
  2000-05-02 22:26       ` Andrea Arcangeli
  2000-05-02 22:02     ` Andrea Arcangeli
  2000-05-02 22:54     ` Andrea Arcangeli
  2 siblings, 2 replies; 16+ messages in thread
From: Linus Torvalds @ 2000-05-02 21:40 UTC (permalink / raw)
  To: Juan J. Quintela; +Cc: linux-mm, Andrea Arcangeli, Kanoj Sarcar


On 2 May 2000, Juan J. Quintela wrote:
> 
> <self package advertising> 
> I can reproduce this BUGs easily with the mmap002 program from the
> memtest-0.0.3 suite (http://carpanta.dc.fi.udc.es/~quintela/memtest/).
> You need to change the #define RAMSIZE to reflect your memory size in
> include file misc_lib.h and you run it in one while(true); do
> ./mmap002; done and in the 8th, 9th execution it Oops here also.
> </self package advertising>

Ok, I'll try that..

> If you want the patch for get rid of PG_swap_entry, I can do it and send it to
> you.

I'd rather get rid of it entirely, yes, as I hate having "crud" around
that nobody realizes isn't really even active any more (and your one-liner
de-activates the whole thing as far as I can tell).

		Linus

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 21:31   ` Juan J. Quintela
  2000-05-02 21:40     ` Linus Torvalds
@ 2000-05-02 22:02     ` Andrea Arcangeli
  2000-05-02 22:13       ` Juan J. Quintela
  2000-05-03  0:43       ` Andrea Arcangeli
  2000-05-02 22:54     ` Andrea Arcangeli
  2 siblings, 2 replies; 16+ messages in thread
From: Andrea Arcangeli @ 2000-05-02 22:02 UTC (permalink / raw)
  To: Juan J. Quintela; +Cc: Linus Torvalds, linux-mm, Kanoj Sarcar

On 2 May 2000, Juan J. Quintela wrote:

><self package advertising> 
>I can reproduce this BUGs easily with the mmap002 program from the
>memtest-0.0.3 suite (http://carpanta.dc.fi.udc.es/~quintela/memtest/).
>You need to change the #define RAMSIZE to reflect your memory size in
>include file misc_lib.h and you run it in one while(true); do
>./mmap002; done and in the 8th, 9th execution it Oops here also.
></self package advertising>

I'll try this, thanks.

>If you want the patch for get rid of PG_swap_entry, I can do it and send
>it to you.

The PG_swap_entry isn't going to be the problem. However if you fear about
it try out this patch on top of 2.3.99-pre6. If PG_swap_entry is the
problem you'll get your problem fixed.

--- 2.3.99-pre6/mm/swapfile.c	Thu Apr 27 17:56:45 2000
+++ /tmp/swapfile.c	Tue May  2 23:57:24 2000
@@ -207,7 +207,7 @@
 	unsigned long offset, type;
 	swp_entry_t entry;
 
-	if (!PageSwapEntry(page))
+	if (1 || !PageSwapEntry(page))
 		goto new_swap_entry;
 
 	/* We have the old entry in the page offset still */

Just a thought, do you use NFS? If so please give a try without NFS
filesystem mounted. I should have addressed the NFS troubles in my current
tree but it's still under testing.

Andrea

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 21:40     ` Linus Torvalds
@ 2000-05-02 22:06       ` Juan J. Quintela
  2000-05-02 22:26       ` Andrea Arcangeli
  1 sibling, 0 replies; 16+ messages in thread
From: Juan J. Quintela @ 2000-05-02 22:06 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-mm, Andrea Arcangeli, Kanoj Sarcar

>>>>> "linus" == Linus Torvalds <torvalds@transmeta.com> writes:

Hi

>> If you want the patch for get rid of PG_swap_entry, I can do it and send it to
>> you.

linus> I'd rather get rid of it entirely, yes, as I hate having "crud" around
linus> that nobody realizes isn't really even active any more (and your one-liner
linus> de-activates the whole thing as far as I can tell).

Attached is the patch that removes all the PG_swap_entry logic, the
*SwapEntry macros, and the acquire_swap_entry function.  This function
becomes a call to get_swap_page.  I have substituted that.

Later, Juan.

diff -u -urN --exclude=CVS --exclude=*~ --exclude=.#* pre7-1/include/linux/mm.h swap_entry/include/linux/mm.h
--- pre7-1/include/linux/mm.h	Sat Apr 29 20:53:36 2000
+++ swap_entry/include/linux/mm.h	Tue May  2 23:51:16 2000
@@ -173,7 +173,7 @@
 #define PG_slab			 8
 #define PG_swap_cache		 9
 #define PG_skip			10
-#define PG_swap_entry		11
+#define PG_unused_03		11
 #define PG_highmem		12
 				/* bits 21-30 unused */
 #define PG_reserved		31
@@ -210,9 +210,6 @@
 #define PageClearSwapCache(page)	clear_bit(PG_swap_cache, &(page)->flags)
 
 #define PageTestandClearSwapCache(page)	test_and_clear_bit(PG_swap_cache, &(page)->flags)
-#define PageSwapEntry(page)		test_bit(PG_swap_entry, &(page)->flags)
-#define SetPageSwapEntry(page)		set_bit(PG_swap_entry, &(page)->flags)
-#define ClearPageSwapEntry(page)	clear_bit(PG_swap_entry, &(page)->flags)
 
 #ifdef CONFIG_HIGHMEM
 #define PageHighMem(page)		test_bit(PG_highmem, &(page)->flags)
diff -u -urN --exclude=CVS --exclude=*~ --exclude=.#* pre7-1/include/linux/swap.h swap_entry/include/linux/swap.h
--- pre7-1/include/linux/swap.h	Thu Apr 27 00:29:07 2000
+++ swap_entry/include/linux/swap.h	Tue May  2 23:54:50 2000
@@ -121,7 +121,6 @@
 					struct inode **);
 extern int swap_duplicate(swp_entry_t);
 extern int swap_count(struct page *);
-extern swp_entry_t acquire_swap_entry(struct page *page);
 extern int valid_swaphandles(swp_entry_t, unsigned long *);
 #define get_swap_page() __get_swap_page(1)
 extern void __swap_free(swp_entry_t, unsigned short);
diff -u -urN --exclude=CVS --exclude=*~ --exclude=.#* pre7-1/mm/memory.c swap_entry/mm/memory.c
--- pre7-1/mm/memory.c	Tue Apr 25 00:46:18 2000
+++ swap_entry/mm/memory.c	Tue May  2 23:51:53 2000
@@ -1053,8 +1053,6 @@
 
 	pte = mk_pte(page, vma->vm_page_prot);
 
-	SetPageSwapEntry(page);
-
 	/*
 	 * Freeze the "shared"ness of the page, ie page_count + swap_count.
 	 * Must lock page before transferring our swap count to already
diff -u -urN --exclude=CVS --exclude=*~ --exclude=.#* pre7-1/mm/swap_state.c swap_entry/mm/swap_state.c
--- pre7-1/mm/swap_state.c	Wed Apr 26 02:28:56 2000
+++ swap_entry/mm/swap_state.c	Tue May  2 23:52:39 2000
@@ -130,9 +130,6 @@
 		}
 		UnlockPage(page);
 	}
-
-	ClearPageSwapEntry(page);
-
 	__free_page(page);
 }
 
diff -u -urN --exclude=CVS --exclude=*~ --exclude=.#* pre7-1/mm/swapfile.c swap_entry/mm/swapfile.c
--- pre7-1/mm/swapfile.c	Fri Apr 21 22:36:40 2000
+++ swap_entry/mm/swapfile.c	Tue May  2 23:54:44 2000
@@ -200,49 +200,6 @@
 	goto out;
 }
 
-/* needs the big kernel lock */
-swp_entry_t acquire_swap_entry(struct page *page)
-{
-	struct swap_info_struct * p;
-	unsigned long offset, type;
-	swp_entry_t entry;
-
-	if (!PageSwapEntry(page))
-		goto new_swap_entry;
-
-	/* We have the old entry in the page offset still */
-	if (!page->index)
-		goto new_swap_entry;
-	entry.val = page->index;
-	type = SWP_TYPE(entry);
-	if (type >= nr_swapfiles)
-		goto new_swap_entry;
-	p = type + swap_info;
-	if ((p->flags & SWP_WRITEOK) != SWP_WRITEOK)
-		goto new_swap_entry;
-	offset = SWP_OFFSET(entry);
-	if (offset >= p->max)
-		goto new_swap_entry;
-	/* Has it been re-used for something else? */
-	swap_list_lock();
-	swap_device_lock(p);
-	if (p->swap_map[offset])
-		goto unlock_new_swap_entry;
-
-	/* We're cool, we can just use the old one */
-	p->swap_map[offset] = 1;
-	swap_device_unlock(p);
-	nr_swap_pages--;
-	swap_list_unlock();
-	return entry;
-
-unlock_new_swap_entry:
-	swap_device_unlock(p);
-	swap_list_unlock();
-new_swap_entry:
-	return get_swap_page();
-}
-
 /*
  * The swap entry has been read in advance, and we return 1 to indicate
  * that the page has been used or is no longer needed.
diff -u -urN --exclude=CVS --exclude=*~ --exclude=.#* pre7-1/mm/vmscan.c swap_entry/mm/vmscan.c
--- pre7-1/mm/vmscan.c	Sat Apr 29 20:53:36 2000
+++ swap_entry/mm/vmscan.c	Tue May  2 23:54:36 2000
@@ -151,7 +151,7 @@
 	 * we have the swap cache set up to associate the
 	 * page with that swap entry.
 	 */
-	entry = acquire_swap_entry(page);
+	entry = get_swap_page();
 	if (!entry.val)
 		goto out_failed; /* No swap space left */
 		




-- 
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02  1:08 Oops in __free_pages_ok (pre7-1) (Long) Juan J. Quintela
  2000-05-02 20:43 ` Linus Torvalds
@ 2000-05-02 22:08 ` Andrea Arcangeli
  2000-05-02 23:58   ` Juan J. Quintela
  1 sibling, 1 reply; 16+ messages in thread
From: Andrea Arcangeli @ 2000-05-02 22:08 UTC (permalink / raw)
  To: Juan J. Quintela; +Cc: linux-mm, Linus Torvalds, Kanoj Sarcar

On 2 May 2000, Juan J. Quintela wrote:

>swap_entry bit, but not agreement in which is the correct one.

My latest one is the correct one but I would also use the atomic operation
in shrink_mmap even if we hold the page lock to be fully safe. I have an
assert that BUG if a page is freed with such bit set and it never triggers
since I noticed the few problematic places thanks to Ben.

>diff -u -urN --exclude=CVS --exclude=*~ --exclude=.#* pre7-1plus/mm/memory.c lin
>ux/mm/memory.c
>--- pre7-1plus/mm/memory.c      Tue Apr 25 00:46:18 2000
>+++ linux/mm/memory.c   Tue May  2 00:36:13 2000
>@@ -1053,7 +1053,7 @@
> 
>        pte = mk_pte(page, vma->vm_page_prot);
> 
>-       SetPageSwapEntry(page);
>+       /*      SetPageSwapEntry(page);  */
> 
>        /*
>         * Freeze the "shared"ness of the page, ie page_count + swap_count.

Are you sure it solves the problem? Could you try also the other patch I
sent you in the email of 1 minute ago? that should be even more effective.

I'll let you know what happens here...

Andrea

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 22:02     ` Andrea Arcangeli
@ 2000-05-02 22:13       ` Juan J. Quintela
  2000-05-03  0:43       ` Andrea Arcangeli
  1 sibling, 0 replies; 16+ messages in thread
From: Juan J. Quintela @ 2000-05-02 22:13 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: Linus Torvalds, linux-mm, Kanoj Sarcar

>>>>> "andrea" == Andrea Arcangeli <andrea@suse.de> writes:

Hi

>> If you want the patch for get rid of PG_swap_entry, I can do it and send
>> it to you.

andrea> The PG_swap_entry isn't going to be the problem. However if you fear about
andrea> it try out this patch on top of 2.3.99-pre6. If PG_swap_entry is the
andrea> problem you'll get your problem fixed.

Andrea, I have done basically the same patch (see my post to the list
yesterday),  I commented the line that set the PG_swap_entry bit.  (My
patch has the same net effect).  And now my systems don't crash, I
don't trigger more BUGS. 


andrea> Just a thought, do you use NFS? If so please give a try without NFS
andrea> filesystem mounted. I should have addressed the NFS troubles in my current
andrea> tree but it's still under testing.

Yes, I use NFS, but all the test has been done in ext2 local
file systems.  I had at that time mounted NFS partitions, but I was not
using them, make that any difference?

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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 21:40     ` Linus Torvalds
  2000-05-02 22:06       ` Juan J. Quintela
@ 2000-05-02 22:26       ` Andrea Arcangeli
  2000-05-03  0:38         ` Andrea Arcangeli
  1 sibling, 1 reply; 16+ messages in thread
From: Andrea Arcangeli @ 2000-05-02 22:26 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Juan J. Quintela, linux-mm, Kanoj Sarcar

On Tue, 2 May 2000, Linus Torvalds wrote:

>I'd rather get rid of it entirely, yes, as I hate having "crud" around

We can get rid of it entirely if you want, it's only an optimization.

The object of the swap entry bitflag is _only_ to swapout the same page in
the same place across a swapin-write fault. It seems to do the trick to
me.

Making swap cache dirty will take a swap entry locked indefinitely (well,
really also swapin read fault take swap entry locked indefinitely...) and
it have to be a kind of dirty swap cache that doesn't get written to disk
in the usual behaviour but it have to be written to disk only when we go
low on memory and we try to unmap it. The only advantage of dirty cache
over swap-entry-logic is that we can do write-swapin/swapout without
dropping the buffer headers from the page in between but the buffer
headers could go away very fast anyway due memory pressure...

>that nobody realizes isn't really even active any more (and your one-liner

The trick is still active (too much active since sometime we forget to
clear the bitflag ;).

If you want to drop it let me know.

Andrea

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 21:31   ` Juan J. Quintela
  2000-05-02 21:40     ` Linus Torvalds
  2000-05-02 22:02     ` Andrea Arcangeli
@ 2000-05-02 22:54     ` Andrea Arcangeli
  2 siblings, 0 replies; 16+ messages in thread
From: Andrea Arcangeli @ 2000-05-02 22:54 UTC (permalink / raw)
  To: Juan J. Quintela; +Cc: linux-mm

On 2 May 2000, Juan J. Quintela wrote:

>You need to change the #define RAMSIZE to reflect your memory size in

hint: ramsize asks for not being a compile time thing ;)

Andrea

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 22:08 ` Andrea Arcangeli
@ 2000-05-02 23:58   ` Juan J. Quintela
  0 siblings, 0 replies; 16+ messages in thread
From: Juan J. Quintela @ 2000-05-02 23:58 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: linux-mm, Linus Torvalds, Kanoj Sarcar

>>>>> "andrea" == Andrea Arcangeli <andrea@suse.de> writes:

Hi Andrea

andrea> On 2 May 2000, Juan J. Quintela wrote:
>> swap_entry bit, but not agreement in which is the correct one.

andrea> My latest one is the correct one but I would also use the atomic operation
andrea> in shrink_mmap even if we hold the page lock to be fully safe. I have an
andrea> assert that BUG if a page is freed with such bit set and it never triggers
andrea> since I noticed the few problematic places thanks to Ben.
[...]
andrea> Are you sure it solves the problem? Could you try also the other patch I
andrea> sent you in the email of 1 minute ago? that should be even more effective.

Hi,
        I have just tested 4 changes against 2.3.99-pre7-1:
        (I use also Rik semicolon patch and Al Viro mount-7-1-B
        patch).  The test is:
                 while (true); do time ./mmap002; done

1- I tested without any more patches, it Oops in
   page_alloc.c:__free_pages_ok(): I got a lot of kernel BUG at
   page_alloc.c:104! and one page_alloc.c:102.  This is in the second
   iteration. See the Oops attached.


2- I tested with Andrea patch, make in acquire_swap_entry to always
   allocate a new swap_entry, i.e. Don't use the PG_swap_entry
   information.  No problems after 18 iterations.

3- I tested with my patch (never set the PG_swap_entry bit).  No
   problem after 16 iterations.

4- I added a test in __free_pages_ok, checking for the PG_swap_entry
   bit.

--- testing/mm/page_alloc.c     Mon May  1 18:34:49 2000
+++ pre7-1plus/mm/page_alloc.c  Wed May  3 01:06:26 2000
@@ -110,6 +110,8 @@
                BUG();
        if (PageDecrAfter(page))
                BUG();
+       if (PageSwapEntry(page))
+               BUG();
 
        zone = page->zone;

this kernel BUG() in the first iteration.  And it does in this new
check.  See the attached Oops reports.

If you need any more information, some more test, let me know.

Later, Juan.

PD. There are 4 identicals machines, K6-2 266Mhz, 96MB RAM, headless,
    and  the only proccess running was that one (except system daemons
    and similars).


1st test. Normal kernel.
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0127029>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000020   ebx: c1000128   ecx: 00000017   edx: 00000000
esi: c1000128   edi: c12f8538   ebp: 00000000   esp: c5fd7ed4
ds: 0018   es: 0018   ss: 0018
Process kswapd (pid: 2, stackpage=c5fd7000)
Stack: c01d02a4 c01d05b2 00000068 c5f96c20 c1000128 c12f8538 c545e240 40c00000 
       41000000 00000004 00000018 00000018 c0126645 4c14f000 c12f8538 4c0b3000 
       4c400000 00043e00 c0126894 c5f96c20 c545e240 4c14e000 c12f8538 00000004 
Call Trace: [<c01d02a4>] [<c01d05b2>] [<c0126645>] [<c0126894>] [<c012695c>] [<c
0126af5>] [<c0126bca>] 
       [<c0126c7a>] [<c0108cc4>] 
Code: 0f 0b 83 c4 0c 89 f6 89 d8 2b 05 6c b9 20 c0 69 c0 39 8e e3 

>>EIP; c0127029 <__free_pages_ok+49/298>   <=====
Trace; c01d02a4 <tvecs+3600/1b87c>
Trace; c01d05b2 <tvecs+390e/1b87c>
Trace; c0126645 <try_to_swap_out+c5/1f4>
Trace; c0126894 <swap_out_vma+120/1ac>
Trace; c012695c <swap_out_mm+3c/68>
Trace; c0126af5 <swap_out+16d/1c0>
Trace; c0126bca <do_try_to_free_pages+82/98>
Trace; c0126c7a <kswapd+9a/11c>
Trace; c0108cc4 <kernel_thread+28/38>
Code;  c0127029 <__free_pages_ok+49/298>
00000000 <_EIP>:
Code;  c0127029 <__free_pages_ok+49/298>   <=====
   0:   0f 0b             ud2a      <=====
Code;  c012702b <__free_pages_ok+4b/298>
   2:   83 c4 0c          addl   $0xc,%esp
Code;  c012702e <__free_pages_ok+4e/298>
   5:   89 f6             movl   %esi,%esi
Code;  c0127030 <__free_pages_ok+50/298>
   7:   89 d8             movl   %ebx,%eax
Code;  c0127032 <__free_pages_ok+52/298>
   9:   2b 05 6c b9 20    subl   0xc020b96c,%eax
Code;  c0127037 <__free_pages_ok+57/298>
   e:   c0 
Code;  c0127038 <__free_pages_ok+58/298>
   f:   69 c0 39 8e e3    imull  $0xe38e39,%eax,%eax
Code;  c012703d <__free_pages_ok+5d/298>
  14:   00 

For the next Oops I put only the traces, if you need more information,
let me know.

>>EIP; c0127029 <__free_pages_ok+49/298>   <=====
Trace; c01d02a4 <tvecs+3600/1b87c>
Trace; c01d05b2 <tvecs+390e/1b87c>
Trace; c011f7ec <shrink_mmap+1b8/2a4>
Trace; c0126b7b <do_try_to_free_pages+33/98>
Trace; c0126d20 <try_to_free_pages+24/34>
Trace; c01274f0 <zone_balance_memory+60/94>
Trace; c01275d1 <__alloc_pages+ad/e0>
Trace; c011dbec <do_anonymous_page+64/e0>
Trace; c011dc98 <do_no_page+30/b0>
Trace; c011de00 <handle_mm_fault+e8/154>
Trace; c01108b7 <do_page_fault+187/4c0>
Trace; c01185e4 <it_real_fn+0/44>
Trace; c011bc27 <update_process_times+5f/68>
Trace; c011bd02 <timer_bh+a2/288>
Trace; c0119133 <bh_action+1b/5c>
Trace; c0119087 <tasklet_hi_action+37/60>
Trace; c0118f82 <do_softirq+52/78>
Trace; c010bd2a <do_IRQ+a2/b8>
Trace; c010ae4d <error_code+2d/40>

Other:
>>EIP; c0127029 <__free_pages_ok+49/298>   <=====
Trace; c01d02a4 <tvecs+3600/1b87c>
Trace; c01d05b2 <tvecs+390e/1b87c>
Trace; c01265de <try_to_swap_out+5e/1f4>
Trace; c0126645 <try_to_swap_out+c5/1f4>
Trace; c0126894 <swap_out_vma+120/1ac>
Trace; c012695c <swap_out_mm+3c/68>
Trace; c0126af5 <swap_out+16d/1c0>
Trace; c0126bca <do_try_to_free_pages+82/98>
Trace; c0126d20 <try_to_free_pages+24/34>
Trace; c01274f0 <zone_balance_memory+60/94>
Trace; c01275d1 <__alloc_pages+ad/e0>
Trace; c0125334 <kmem_cache_grow+10c/404>
Trace; c012580d <kmem_cache_alloc+169/1c4>
Trace; c012c7dd <get_unused_buffer_head+39/b8>
Trace; c012c8dc <create_buffers+20/310>
Trace; c012cda7 <create_empty_buffers+17/70>
Trace; c012d26f <block_read_full_page+63/220>
Trace; c011fc1b <add_to_page_cache_unique+cf/13c>
Trace; c0143c9e <ext2_readpage+e/14>
Trace; c0143600 <ext2_get_block+0/490>
Trace; c011fd70 <read_cluster_nonblocking+e8/140>
Trace; c0121247 <filemap_nopage+1a7/390>
Trace; c011dcb5 <do_no_page+4d/b0>
Trace; c011de00 <handle_mm_fault+e8/154>
Trace; c01108b7 <do_page_fault+187/4c0>
Trace; c011bc27 <update_process_times+5f/68>
Trace; c011bd02 <timer_bh+a2/288>
Trace; c0119133 <bh_action+1b/5c>
Trace; c0119087 <tasklet_hi_action+37/60>
Trace; c011296a <schedule+266/3d8>
Trace; c010ae4d <error_code+2d/40>


Now the Oops for the 4th test:

kernel BUG at page_alloc.c:114!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c01270d9>]
EFLAGS: 00010286
invalid operand: 0000
CPU:    0
EIP:    0010:[<c01270d9>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 00000020   ebx: c1137c48   ecx: 0000003b   edx: c5f96c20
esi: c1137c48   edi: c541dd74   ebp: 00000000   esp: c541dd1c
ds: 0018   es: 0018   ss: 0018
Process mmap002 (pid: 264, stackpage=c541d000)
Stack: c01d02c4 c01d05d2 00000072 c1137c64 c1137c48 c541dd74 00000570 c1137c70 
       c1137c70 00000286 00000023 00000570 c011f859 0000001e 00000002 00000003 
       c020bd4c c541dd7c c541dd74 00000000 c541dd6c c541dd6c c11a9c04 c11ae8cc 
Call Trace: [<c01d02c4>] [<c01d05d2>] [<c011f859>] [<c0126b7b>] [<c0126d20>] [<c
0127510>] [<c01275f1>] 
       [<c0125334>] [<c012c403>] [<c012580d>] [<c012c7fd>] [<c012c8fc>] [<c012cd
c7>] [<c012cea1>] [<c012d795>] 
       [<c0143620>] [<c0143caa>] [<c0143620>] [<c0121458>] [<c0121710>] [<c01218
7a>] [<c012199f>] [<c010ad14>] 
Code: 0f 0b 83 c4 0c 89 f6 8b 73 44 8b 15 8c b9 20 c0 c7 44 24 1c 

>>EIP; c01270d9 <__free_pages_ok+f9/2b8>   <=====
Trace; c01d02c4 <tvecs+3600/1b87c>
Trace; c01d05d2 <tvecs+390e/1b87c>
Trace; c011f859 <shrink_mmap+225/2a4>
Trace; c0126b7b <do_try_to_free_pages+33/98>
Trace; c0126d20 <try_to_free_pages+24/34>
Trace; c0127510 <zone_balance_memory+60/94>
Trace; c01275f1 <__alloc_pages+ad/e0>
Trace; c0125334 <kmem_cache_grow+10c/404>
Trace; c012c403 <getblk+1b/90>
Trace; c012580d <kmem_cache_alloc+169/1c4>
Trace; c012c7fd <get_unused_buffer_head+39/b8>
Trace; c012c8fc <create_buffers+20/310>
Trace; c012cdc7 <create_empty_buffers+17/70>
Trace; c012cea1 <__block_write_full_page+4d/110>
Trace; c012d795 <block_write_full_page+3d/100>
Trace; c0143620 <ext2_get_block+0/490>
Trace; c0143caa <ext2_writepage+e/14>
Trace; c0143620 <ext2_get_block+0/490>
Trace; c0121458 <filemap_write_page+28/48>
Trace; c0121710 <filemap_sync+274/318>
Trace; c012187a <msync_interval+2e/6c>
Trace; c012199f <sys_msync+e7/16c>
Trace; c010ad14 <system_call+34/40>
Code;  c01270d9 <__free_pages_ok+f9/2b8>
00000000 <_EIP>:
Code;  c01270d9 <__free_pages_ok+f9/2b8>   <=====
   0:   0f 0b             ud2a      <=====
Code;  c01270db <__free_pages_ok+fb/2b8>
   2:   83 c4 0c          addl   $0xc,%esp
Code;  c01270de <__free_pages_ok+fe/2b8>
   5:   89 f6             movl   %esi,%esi
Code;  c01270e0 <__free_pages_ok+100/2b8>
   7:   8b 73 44          movl   0x44(%ebx),%esi
Code;  c01270e3 <__free_pages_ok+103/2b8>
   a:   8b 15 8c b9 20    movl   0xc020b98c,%edx
Code;  c01270e8 <__free_pages_ok+108/2b8>
   f:   c0 
Code;  c01270e9 <__free_pages_ok+109/2b8>
  10:   c7 44 24 1c 00    movl   $0x0,0x1c(%esp,1)
Code;  c01270ee <__free_pages_ok+10e/2b8>
  15:   00 00 00 

For the nexts Oops, only the traces also:
>>EIP; c01270d9 <__free_pages_ok+f9/2b8>   <=====
Trace; c01d02c4 <tvecs+3600/1b87c>
Trace; c01d05d2 <tvecs+390e/1b87c>
Trace; c011f859 <shrink_mmap+225/2a4>
Trace; c0126b7b <do_try_to_free_pages+33/98>
Trace; c0126d20 <try_to_free_pages+24/34>
Trace; c0127510 <zone_balance_memory+60/94>
Trace; c01275f1 <__alloc_pages+ad/e0>
Trace; c013924c <alloc_wait+3c/15c>
Trace; c01396a1 <do_select+4d/25c>
Trace; c0139c22 <sys_select+372/488>
Trace; c010ad14 <system_call+34/40>

and another one:

>>EIP; c01270d9 <__free_pages_ok+f9/2b8>   <=====
Trace; c01d02c4 <tvecs+3600/1b87c>
Trace; c01d05d2 <tvecs+390e/1b87c>
Trace; c011f859 <shrink_mmap+225/2a4>
Trace; c0126b7b <do_try_to_free_pages+33/98>
Trace; c0126c7a <kswapd+9a/11c>
Trace; c0108cc4 <kernel_thread+28/38>


-- 
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 22:26       ` Andrea Arcangeli
@ 2000-05-03  0:38         ` Andrea Arcangeli
  2000-05-03  0:45           ` Linus Torvalds
  2000-05-03 10:37           ` Rik van Riel
  0 siblings, 2 replies; 16+ messages in thread
From: Andrea Arcangeli @ 2000-05-03  0:38 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Juan J. Quintela, linux-mm, Kanoj Sarcar

On Wed, 3 May 2000, Andrea Arcangeli wrote:

>Making swap cache dirty will take a swap entry locked indefinitely (well,

I thought some more at it and I think the best thing to do is to reduce
the ability of the swap entry bit. The swap entry bit should keep to be
effective only as far as the page is an anonymous page not shared and it
should never be set on a swap cache page.

Once the swap-entry-page is mapped by more than one process we don't know
anymore which was the original task that was swapped out in such previous
location (if the parent or the child) so during cow we don't know if the
new page or the old page should get the entry bit. I'm not going to
discover that ;).

So what I propose is to set the entry bit in the swapin path only if we
take over the swap cache, and to clear it in do_wp_page during COW and in
free_page_and_swap_cache unconditionally (we know if it's set the page was
not shared). We should also set it while taking over the swap cache in the
cow after removing the page from the swap cache (in the case the page
isn't shared).

This way the swap-entry logic will take care only of the simple case where
a big task gets swapped out then a little part gets swapped in and we'll
try to swapout it again in the same place. That looks sane feature to me.

Note that dirty swap cache during COW have the same problem to choose if
the swap entry should be inherit by the old page or by the new page (so
it's not going to be a solution for that). My conclusion is that dropping
the persistence on the swap during cow looks rasonable action.

Comments?

Andrea

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-02 22:02     ` Andrea Arcangeli
  2000-05-02 22:13       ` Juan J. Quintela
@ 2000-05-03  0:43       ` Andrea Arcangeli
  1 sibling, 0 replies; 16+ messages in thread
From: Andrea Arcangeli @ 2000-05-03  0:43 UTC (permalink / raw)
  To: Juan J. Quintela; +Cc: Linus Torvalds, linux-mm, Kanoj Sarcar

On Wed, 3 May 2000, Andrea Arcangeli wrote:

>On 2 May 2000, Juan J. Quintela wrote:
>
>><self package advertising> 
>>I can reproduce this BUGs easily with the mmap002 program from the
>>memtest-0.0.3 suite (http://carpanta.dc.fi.udc.es/~quintela/memtest/).
>>You need to change the #define RAMSIZE to reflect your memory size in
>>include file misc_lib.h and you run it in one while(true); do
>>./mmap002; done and in the 8th, 9th execution it Oops here also.
>></self package advertising>
>
>I'll try this, thanks.

I reached 23 passes in SMP and nothing happened yet with my latest
lru_cache code plus swap entry patch and classzone stuff. However I can't
exclude it's a timing issue that doesn't allow me to reproduce. As soon as
I'll have finished the rework of the swap entry logic as described in last
email I'll pass you a patch to try out to see if you can reproduce
something weird with it. Thanks.

Andrea

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-03  0:38         ` Andrea Arcangeli
@ 2000-05-03  0:45           ` Linus Torvalds
  2000-05-03  1:28             ` Andrea Arcangeli
  2000-05-03 10:37           ` Rik van Riel
  1 sibling, 1 reply; 16+ messages in thread
From: Linus Torvalds @ 2000-05-03  0:45 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: Juan J. Quintela, linux-mm, Kanoj Sarcar


On Wed, 3 May 2000, Andrea Arcangeli wrote:
> 
> Comments?

Note that as far as I remember, the swap entry thing was introduced
because get_swap_entry() was slow and took up a lot of time.

Let's see if we can just simply drop the swap entry bit, and if required
possibly speed up get_swap_entry some other way. The swap cache access
patterns may be different enough that it might not be that noticeable, for
example (or it might be worse, who knows?)

		Linus

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-03  0:45           ` Linus Torvalds
@ 2000-05-03  1:28             ` Andrea Arcangeli
  0 siblings, 0 replies; 16+ messages in thread
From: Andrea Arcangeli @ 2000-05-03  1:28 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Juan J. Quintela, linux-mm, Kanoj Sarcar

On Tue, 2 May 2000, Linus Torvalds wrote:

>Note that as far as I remember, the swap entry thing was introduced
>because get_swap_entry() was slow and took up a lot of time.

That's a good point too but I was more worried about I/O seek time than CPU
load.

Andrea

--
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] 16+ messages in thread

* Re: Oops in __free_pages_ok (pre7-1) (Long)
  2000-05-03  0:38         ` Andrea Arcangeli
  2000-05-03  0:45           ` Linus Torvalds
@ 2000-05-03 10:37           ` Rik van Riel
  1 sibling, 0 replies; 16+ messages in thread
From: Rik van Riel @ 2000-05-03 10:37 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: Linus Torvalds, Juan J. Quintela, linux-mm, Kanoj Sarcar

On Wed, 3 May 2000, Andrea Arcangeli wrote:

> So what I propose is to set the entry bit in the swapin path only if we
> take over the swap cache, and to clear it in do_wp_page during COW and in
> free_page_and_swap_cache unconditionally (we know if it's set the page was
> not shared). We should also set it while taking over the swap cache in the
> cow after removing the page from the swap cache (in the case the page
> isn't shared).

> Note that dirty swap cache during COW have the same problem to choose if
> the swap entry should be inherit by the old page or by the new page (so
> it's not going to be a solution for that). My conclusion is that dropping
> the persistence on the swap during cow looks rasonable action.

Sounds like a good idea to me.

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] 16+ messages in thread

end of thread, other threads:[~2000-05-03 10:37 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-02  1:08 Oops in __free_pages_ok (pre7-1) (Long) Juan J. Quintela
2000-05-02 20:43 ` Linus Torvalds
2000-05-02 21:31   ` Juan J. Quintela
2000-05-02 21:40     ` Linus Torvalds
2000-05-02 22:06       ` Juan J. Quintela
2000-05-02 22:26       ` Andrea Arcangeli
2000-05-03  0:38         ` Andrea Arcangeli
2000-05-03  0:45           ` Linus Torvalds
2000-05-03  1:28             ` Andrea Arcangeli
2000-05-03 10:37           ` Rik van Riel
2000-05-02 22:02     ` Andrea Arcangeli
2000-05-02 22:13       ` Juan J. Quintela
2000-05-03  0:43       ` Andrea Arcangeli
2000-05-02 22:54     ` Andrea Arcangeli
2000-05-02 22:08 ` Andrea Arcangeli
2000-05-02 23:58   ` Juan J. Quintela

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox