* [RFC][PATCH] Fix area->nr_free-- went (-1) issue in buddy system
@ 2006-12-19 3:01 Aubrey
2006-12-19 3:46 ` Nick Piggin
0 siblings, 1 reply; 5+ messages in thread
From: Aubrey @ 2006-12-19 3:01 UTC (permalink / raw)
To: linux-kernel, linux-mm
Hi all,
When I setup two zones (NORMAL and DMA) in my system, I got the
following wired result from /proc/buddyinfo.
-----------------------------------------------------------------------------------------
root:~> cat /proc/buddyinfo
Node 0, zone DMA 2 1 2 1 1 0 0
1 1 2 2 0 0 0
Node 0, zone Normal 1 1 1 1 1 1 0
0 4294967295 0 4294967295 2 0 0
-----------------------------------------------------------------------------------------
As you see, two area->nr_free went -1.
After dig into the code, I found the problem is in the fun
__free_one_page() when the kernel boot up call free_all_bootmem(). If
two zones setup, it's possible NORMAL zone merged a block whose order
=8 at the first time(this time zone[NORMA]->free_area[8].nr_free = 0)
and found its buddy in the DMA zone. So the two blocks will be merged
and area->nr_free went to -1.
My proposed patch is as follows:
Signed-off-by: Aubrey Li <aubreylee@gmail.com>
---------------------------------------------------------------------------------------------------
--- page_alloc.c.orig 2006-12-19 10:45:25.000000000 +0800
+++ page_alloc.c 2006-12-19 10:44:48.000000000 +0800
@@ -407,7 +407,8 @@ static inline void __free_one_page(struc
list_del(&buddy->lru);
area = zone->free_area + order;
- area->nr_free--;
+ if (area->nr_free > 0)
+ area->nr_free--;
rmv_page_order(buddy);
combined_idx = __find_combined_index(page_idx, order);
page = page + (combined_idx - page_idx);
----------------------------------------------------------------------------------------------------
Any comments?
Thanks,
-Aubrey
--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC][PATCH] Fix area->nr_free-- went (-1) issue in buddy system 2006-12-19 3:01 [RFC][PATCH] Fix area->nr_free-- went (-1) issue in buddy system Aubrey @ 2006-12-19 3:46 ` Nick Piggin 2006-12-19 6:16 ` Aubrey 0 siblings, 1 reply; 5+ messages in thread From: Nick Piggin @ 2006-12-19 3:46 UTC (permalink / raw) To: Aubrey; +Cc: linux-kernel, linux-mm Aubrey wrote: > Hi all, > > When I setup two zones (NORMAL and DMA) in my system, I got the > following wired result from /proc/buddyinfo. > ----------------------------------------------------------------------------------------- > > root:~> cat /proc/buddyinfo > Node 0, zone DMA 2 1 2 1 1 0 0 > 1 1 2 2 0 0 0 > Node 0, zone Normal 1 1 1 1 1 1 0 > 0 4294967295 0 4294967295 2 0 0 > ----------------------------------------------------------------------------------------- > > > As you see, two area->nr_free went -1. > > After dig into the code, I found the problem is in the fun > __free_one_page() when the kernel boot up call free_all_bootmem(). If > two zones setup, it's possible NORMAL zone merged a block whose order > =8 at the first time(this time zone[NORMA]->free_area[8].nr_free = 0) > and found its buddy in the DMA zone. So the two blocks will be merged > and area->nr_free went to -1. This should not happen because the pages are checked to ensure they are from the same zone before merging. What kind of system do you have? What is the dmesg and the .config? It could be that the zones are not properly aligned and CONFIG_HOLES_IN_ZONE is not set. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC][PATCH] Fix area->nr_free-- went (-1) issue in buddy system 2006-12-19 3:46 ` Nick Piggin @ 2006-12-19 6:16 ` Aubrey 2006-12-19 6:34 ` Nick Piggin 0 siblings, 1 reply; 5+ messages in thread From: Aubrey @ 2006-12-19 6:16 UTC (permalink / raw) To: Nick Piggin; +Cc: linux-kernel, linux-mm [-- Attachment #1: Type: text/plain, Size: 1196 bytes --] Hi Nick, Thanks for your reply again, ;-). On 12/19/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > This should not happen because the pages are checked to ensure they are > from the same zone before merging. How? page_is_buddy() only check if the buddy has the buddy flag and has the same order. Where can I find the same zone is checked? > > What kind of system do you have? What is the dmesg and the .config? I'm using the blackfin uclinux. dmesg and .config is attached. > It could be that the zones are not properly aligned and CONFIG_HOLES_IN_ZONE > is not set. I changed the code in paging_init(), see below: ----------------------------------------- #if 0 zones_size[ZONE_DMA] = (end_mem - PAGE_OFFSET) >> PAGE_SHIFT; zones_size[ZONE_NORMAL] = 0; #else zones_size[ZONE_DMA] = (end_mem/2 - PAGE_OFFSET) >> PAGE_SHIFT; zones_size[ZONE_NORMAL] = (end_mem/2 - PAGE_OFFSET) >> PAGE_SHIFT; #endif ----------------------------------------- This is only what I did the change. I also suspect the zones are not properly aligned, But how to align it? I think our system doesn't need CONFIG_HOLES_IN_ZONE. Thanks, -Aubrey [-- Attachment #2: dmesg.txt --] [-- Type: text/plain, Size: 3321 bytes --] root:~> dmesg Linux version 2.6.16.27-ADI-2006R2 (aubrey@suse10) (gcc version 4.1.1 (ADI 06R2)) #2 Tue Dec 19 14:03:41 CST 2006 Blackfin support (C) 2004-2006 Analog Devices, Inc. Compiled for ADSP-BF537 Rev. 0.2 Blackfin uClinux support by http://blackfin.uclinux.org/ Processor Speed: 500 MHz core clock and 100 Mhz System Clock Board Memory: 48MB Kernel Managed Memory: 48MB Memory map: text = 0x00001000-0x0011cd18 init = 0x0011d000-0x0012b9b0 data = 0x0012bfdc-0x00151aa4 stack = 0x0012c000-0x0012e000 bss = 0x00151ab0-0x001600b4 available = 0x001600b4-0x02700000 rootfs = 0x02700000-0x02f00000 DMA Zone = 0x02f00000-0x03000000 On node 0 totalpages: 9984 DMA zone: 4992 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 4992 pages, LIFO batch:0 HighMem zone: 0 pages, LIFO batch:0 Instruction Cache Enabled Data Cache Enabled (write-through) Hardware Trace Enabled Built 1 zonelists Kernel command line: root=/dev/mtdblock0 rw mem=48M ip=192.168.0.8:192.168.0.2:10.99.22.1:255.255.255.0:BF537:eth0:off Configuring Blackfin Priority Driven Interrupts PID hash table entries: 256 (order: 8, 4096 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Physical pages: 2700 Memory available: 38144k/47952k RAM, (58k init code, 1135k kernel code, 57k data, 1024k dma) Blackfin Scratchpad data SRAM: 4 KB Blackfin DATA_A SRAM: 16 KB Blackfin DATA_B SRAM: 16 KB Blackfin Instruction SRAM: 48 KB Calibrating delay loop... 995.32 BogoMIPS (lpj=1990656) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 NET: Registered protocol family 16 Blackfin DMA Controller stamp_init(): registering device resources NET: Registered protocol family 23 io scheduler noop registered io scheduler anticipatory registered (default) io scheduler cfq registered Real Time Clock Driver v1.10e Dynamic Power Management Controller Driver v0.1: major=10, minor = 254 Blackfin BF5xx serial driver version 2.00 (DMA mode) RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Blackfin mac net device registered uclinux[mtd]: RAM probe address=0x2700000 size=0x800000 Creating 1 MTD partitions on "RAM": 0x00000000-0x00800000 : "ROMfs" uclinux[mtd]: set ROMfs:EXT2 to be root filesystem NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 1, 8192 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 IrCOMM protocol (Dag Brattli) IP-Config: Gateway not on directly connected network. VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 56k freed (0x11d000 - 0x12a000) ttyS0 at irq = 18 is a builtin Blackfin UART dma_alloc_init: dma_page @ 0x0242d000 - 256 pages at 0x02f00000 root:~> cat /proc/buddyinfo Node 0, zone DMA 4 3 1 2 1 1 0 1 1 2 1 1 0 0 Node 0, zone Normal 3 1 2 2 1 1 0 0 4294967295 0 0 0 1 0 [-- Attachment #3: kerne.config --] [-- Type: application/x-config, Size: 18016 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC][PATCH] Fix area->nr_free-- went (-1) issue in buddy system 2006-12-19 6:16 ` Aubrey @ 2006-12-19 6:34 ` Nick Piggin 2006-12-19 7:41 ` Aubrey 0 siblings, 1 reply; 5+ messages in thread From: Nick Piggin @ 2006-12-19 6:34 UTC (permalink / raw) To: Aubrey; +Cc: linux-kernel, linux-mm Hi Aubery! Aubrey wrote: > Hi Nick, > > Thanks for your reply again, ;-). > > On 12/19/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote: > >> >> This should not happen because the pages are checked to ensure they are >> from the same zone before merging. > > > How? page_is_buddy() only check if the buddy has the buddy flag and > has the same order. > Where can I find the same zone is checked? Ah OK, you're using 2.6.16? Later kernels have a check for this. I guess you could backport it? > >> >> What kind of system do you have? What is the dmesg and the .config? > > > I'm using the blackfin uclinux. dmesg and .config is attached. > >> It could be that the zones are not properly aligned and >> CONFIG_HOLES_IN_ZONE >> is not set. > > > I changed the code in paging_init(), see below: > ----------------------------------------- > #if 0 > zones_size[ZONE_DMA] = (end_mem - PAGE_OFFSET) >> > PAGE_SHIFT; > zones_size[ZONE_NORMAL] = 0; > #else > zones_size[ZONE_DMA] = (end_mem/2 - PAGE_OFFSET) >> > PAGE_SHIFT; > zones_size[ZONE_NORMAL] = (end_mem/2 - PAGE_OFFSET) >> > PAGE_SHIFT; > #endif > ----------------------------------------- > This is only what I did the change. I also suspect the zones are not > properly aligned, But how to align it? I think our system doesn't need > CONFIG_HOLES_IN_ZONE. That's right. I guess you can either align your zone sizes (must be aligned to MAX_ORDER size), or add the zone check in page_is_buddy. Hope that works. Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC][PATCH] Fix area->nr_free-- went (-1) issue in buddy system 2006-12-19 6:34 ` Nick Piggin @ 2006-12-19 7:41 ` Aubrey 0 siblings, 0 replies; 5+ messages in thread From: Aubrey @ 2006-12-19 7:41 UTC (permalink / raw) To: Nick Piggin; +Cc: linux-kernel, linux-mm On 12/19/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote: > Hi Aubery! > > That's right. I guess you can either align your zone sizes (must be > aligned to MAX_ORDER size), or add the zone check in page_is_buddy. > Adding the zone check in page_is_buddy fix the problem. Thanks again, :) -Aubrey -- 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-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-12-19 7:41 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-12-19 3:01 [RFC][PATCH] Fix area->nr_free-- went (-1) issue in buddy system Aubrey 2006-12-19 3:46 ` Nick Piggin 2006-12-19 6:16 ` Aubrey 2006-12-19 6:34 ` Nick Piggin 2006-12-19 7:41 ` Aubrey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox