[PATCH] remove unnecessary PAE pgd set

With PAE on, there are only 4 PGD entries.  The kernel ones never
change, so there is no need to copy them when a vmalloc fault occurs.
This was this was causing problems with the split pmd patches, but it is
still correct for mainline.

Tested with and without PAE.  I ran it in a loop turning on and off 10
swap partitions, which is what excited the original bug.
http://bugme.osdl.org/show_bug.cgi?id=640
-- 
Dave Hansen
haveblue <at> us.ibm.com

--- linux-2.5.68-vmal_fault/arch/i386/mm/fault.c.orig	Wed Apr 30 13:36:49 2003
+++ linux-2.5.68-vmal_fault/arch/i386/mm/fault.c	Wed Apr 30 13:36:18 2003
 <at>  <at>  -405,7 +405,15  <at>  <at> 

 		if (!pgd_present(*pgd_k))
 			goto no_context;
+		/*
+		 * kernel pmd pages are shared among all processes
+		 * with PAE on.  Since vmalloc pages are always
+		 * in the kernel area, this will always be a 
+		 * waste with PAE on.
+		 */
+#ifndef CONFIG_X86_PAE
 		set_pgd(pgd, *pgd_k);
+#endif
 		
 		pmd = pmd_offset(pgd, address);

Re: 2.5.68-mm3

On April 30, 2003 02:59 am, Andrew Morton wrote:
> Bits and pieces.  Nothing major, apart from the dynamic request allocation
> patch.  This arbitrarily increases the maximum requests/queue to 1024, and
> could well make large (and usually bad) changes to various benchmarks.
> However some will be helped.

Here is something a little broken.  Suspect it might be in 68-bk too:

if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.5.68-mm3; fi
WARNING: /lib/modules/2.5.68-mm3/kernel/sound/oss/cs46xx.ko needs unknown symbol cs4x_ClearPageReserved

Ed Tomlinson
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>

Re: 2.5.68-mm3

Ed Tomlinson <tomlins <at> cam.org> wrote:
>
> On April 30, 2003 02:59 am, Andrew Morton wrote:
> > Bits and pieces.  Nothing major, apart from the dynamic request allocation
> > patch.  This arbitrarily increases the maximum requests/queue to 1024, and
> > could well make large (and usually bad) changes to various benchmarks.
> > However some will be helped.
> 
> Here is something a little broken.  Suspect it might be in 68-bk too:
> 
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.5.68-mm3; fi
> WARNING: /lib/modules/2.5.68-mm3/kernel/sound/oss/cs46xx.ko needs unknown symbol cs4x_ClearPageReserved
> 

Yes, thanks.  It's a case of search-n-replace-n-dont-test.

diff -puN sound/oss/cs46xx.c~cs46xx-PageReserved-fix sound/oss/cs46xx.c
--- 25/sound/oss/cs46xx.c~cs46xx-PageReserved-fix	Wed Apr 30 17:03:41 2003
+++ 25-akpm/sound/oss/cs46xx.c	Wed Apr 30 17:03:48 2003
 <at>  <at>  -1247,7 +1247,7  <at>  <at>  static void dealloc_dmabuf(struct cs_sta
 		mapend = virt_to_page(dmabuf->rawbuf + 
 				(PAGE_SIZE << dmabuf->buforder) - 1);
 		for (map = virt_to_page(dmabuf->rawbuf); map <= mapend; map++)
-			cs4x_ClearPageReserved(map);
+			ClearPageReserved(map);
 		free_dmabuf(state->card, dmabuf);
 	}

 <at>  <at>  -1256,7 +1256,7  <at>  <at>  static void dealloc_dmabuf(struct cs_sta
 		mapend = virt_to_page(dmabuf->tmpbuff +

Re: 2.5.68-mm3

i think this has been reported for linus's tree, but i noticed it with
-mm3

Steve

make -f scripts/Makefile.build obj=drivers/ieee1394
  gcc -Wp,-MD,drivers/ieee1394/.nodemgr.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=athlon
-Iinclude/asm-i386/mach-default -fomit-frame-pointer -nostdinc
-iwithprefix include    -DKBUILD_BASENAME=nodemgr
-DKBUILD_MODNAME=ieee1394 -c -o drivers/ieee1394/.tmp_nodemgr.o
drivers/ieee1394/nodemgr.c
drivers/ieee1394/nodemgr.c: In function `nodemgr_bus_match':
drivers/ieee1394/nodemgr.c:367: structure has no member named
`class_num'
drivers/ieee1394/nodemgr.c: At top level:
drivers/ieee1394/nodemgr.c:497: unknown field `class_num' specified in
initializer
drivers/ieee1394/nodemgr.c:497: warning: excess elements in struct
initializer
drivers/ieee1394/nodemgr.c:497: warning: (near initialization for
`nodemgr_dev_template_ud')
drivers/ieee1394/nodemgr.c:503: unknown field `class_num' specified in
initializer
drivers/ieee1394/nodemgr.c:503: warning: excess elements in struct
initializer
drivers/ieee1394/nodemgr.c:503: warning: (near initialization for
`nodemgr_dev_template_ne')
drivers/ieee1394/nodemgr.c:508: unknown field `class_num' specified in

Re: [PATCH] remove unnecessary PAE pgd set

On Wed, Apr 30, 2003 at 04:42:25PM -0700, Dave Hansen wrote:
> With PAE on, there are only 4 PGD entries.  The kernel ones never
> change, so there is no need to copy them when a vmalloc fault occurs.
> This was this was causing problems with the split pmd patches, but it is
> still correct for mainline.
> Tested with and without PAE.  I ran it in a loop turning on and off 10
> swap partitions, which is what excited the original bug.
> http://bugme.osdl.org/show_bug.cgi?id=640

I suspect this set_pgd() should go away for non-PAE also.

-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>

Re: [PATCH] remove unnecessary PAE pgd set

William Lee Irwin III wrote:
> On Wed, Apr 30, 2003 at 04:42:25PM -0700, Dave Hansen wrote:
> 
>>With PAE on, there are only 4 PGD entries.  The kernel ones never
>>change, so there is no need to copy them when a vmalloc fault occurs.
>>This was this was causing problems with the split pmd patches, but it is
>>still correct for mainline.
>>Tested with and without PAE.  I ran it in a loop turning on and off 10
>>swap partitions, which is what excited the original bug.
>>http://bugme.osdl.org/show_bug.cgi?id=640
> 
> I suspect this set_pgd() should go away for non-PAE also.

Wouldn't it be analogous to the PMD set with PAE on, and necessary?
Since processes don't share PGDs in 4G mode, the PGD entry could be
missing in a process's pagetables after the kernel ones have been filled
in.  That set_pgd() will be necessary to move any new entry over.

- a process does a vmalloc, which eventually calls pte_alloc_kernel()
- pte_alloc_kernel() is always called with init_mm as its mm argument
- pte_alloc_kernel() populates init_mm PGD entries with the new pte page
- the process goes to use its new vmalloc'd area, and faults, because
  its pgd doesn't have the same entries.  do_page_fault():vmalloc_fault
  brings over the necessary entries from init, and the fault is handled

The other option is to hold mmlist_lock and populate the entries around
when pte_alloc_kernel() is called.  The lazy way is better because not
every process will go looking into the vmalloc area, _and_ and new pgds
should be copied from the init one anyway, and inherit the PTE mapping.
 The lazy update only needs to be done for processes when their PGDs

Re: [PATCH] remove unnecessary PAE pgd set

William Lee Irwin III wrote:
>> I suspect this set_pgd() should go away for non-PAE also.

On Wed, Apr 30, 2003 at 08:39:04PM -0700, Dave Hansen wrote:
> Wouldn't it be analogous to the PMD set with PAE on, and necessary?
> Since processes don't share PGDs in 4G mode, the PGD entry could be
> missing in a process's pagetables after the kernel ones have been filled
> in.  That set_pgd() will be necessary to move any new entry over.

Not really; it should just fall through to the pmd "level", which as
emulated should do all the instantiation needed for non-PAE.

On Wed, Apr 30, 2003 at 08:39:04PM -0700, Dave Hansen wrote:
> - a process does a vmalloc, which eventually calls pte_alloc_kernel()
> - pte_alloc_kernel() is always called with init_mm as its mm argument
> - pte_alloc_kernel() populates init_mm PGD entries with the new pte page
> - the process goes to use its new vmalloc'd area, and faults, because
>   its pgd doesn't have the same entries.  do_page_fault():vmalloc_fault
>   brings over the necessary entries from init, and the fault is handled

Sounds like a good plan to me.

On Wed, Apr 30, 2003 at 08:39:04PM -0700, Dave Hansen wrote:
> The other option is to hold mmlist_lock and populate the entries around
> when pte_alloc_kernel() is called.  The lazy way is better because not
> every process will go looking into the vmalloc area, _and_ and new pgds
> should be copied from the init one anyway, and inherit the PTE mapping.
>  The lazy update only needs to be done for processes when their PGDs
> were allocated in the past.

[BUG] 2.5.68-mm2 and list.h

Andrew Morton <akpm <at> digeo.com> writes:
>
> [SNIP]
>

Caught this one on boot:

drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0
Bluetooth: Core ver 2.2
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: HCI USB driver ver 2.1
drivers/usb/core/usb.c: registered new driver hci_usb
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
------------[ cut here ]------------
kernel BUG at include/linux/list.h:140!
invalid operand: 0000 [#1]
CPU:    0
EIP:    0060:[<c011acc2>]    Not tainted VLI
EFLAGS: 00010083
EIP is at remove_wait_queue+0x66/0x70
eax: ec937d94   ebx: ec936000   ecx: ec937da0   edx: ec797d28
esi: 00000286   edi: ec937d94   ebp: ec937d58   esp: ec937d50
ds: 007b   es: 007b   ss: 0068
Process logger (pid: 3942, threadinfo=ec936000 task=edede700)
Stack: ec797d28 ec936000 ec937dc0 c019e462 c02fff00 00000002 c0117b14 ec797d24
       effb1600 00000000 edede700 c0119716 00000000 00000000 00000000 ec937ee7
       ecaa5df0 00000000 edede700 c0119716 ec797d28 ec797d28 ec937ee7 0026c8ca
Call Trace:

Re: [BUG] 2.5.68-mm2 and list.h

Alexander Hoogerhuis <alexh <at> ihatent.com> wrote:
>
> kernel BUG at include/linux/list.h:140!
> Call Trace:
>  [<c019e462>] devfs_d_revalidate_wait+0x181/0x18d

Yes.  Apparently, devfs has some programming flaws.

For now, please just delete the new debug tests in
include/linux/list.h:list_del():

#include <linux/kernel.h>       /* BUG_ON */
static inline void list_del(struct list_head *entry)
{
	BUG_ON(entry->prev->next != entry);
	BUG_ON(entry->next->prev != entry);
	__list_del(entry->prev, entry->next);
}

Those BUG_ON's.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>

Re: [BUG 2.4] Buffers Span Zones

Ross Biro <rossb <at> google.com> wrote:
>
> It appears that in the 2.4 kernels, kswapd is 
> not aware that buffer heads can be in one zone while the buffers 
> themselves are in another zone.

What Martin said...

This problem has a fix in Andrea's kernel.  I broke out his VM changes a
while back but seem to have lost that one.  hmm.  I have an old version,
below.

Fixes exist in 2.5.

> It also appears that in buffer.c balance_dirty_state really needs to be 
> zone aware as well.

Not really - the arithmetic in there only takes into account the size of
ZONE_NORMAL+ZONE_DMA anyway.  nr_free_buffer_pages().

> It might also be nice to replace many of the 
> current->policy |= YIELD; schedule(); pairs with real waits for memory 
> to free up a bit.  If dirty pages or associated structures are filling 
> up most of the memory, then the problem will go away if we just wait a bit.

2.5 does this.  It's a bit crude, but works sufficiently well to have not
made a nuisance of itself in six months or so.

Addresses the problem where all of ZONE_NORMAL is full of buffer_heads.
 Normal page reclaim will view all this memory as non-freeable.