Re: WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170()
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
In changelog, Bartlomiej said. My particular test case (on a ARM EXYNOS4 device with 512 MiB, which means 131072 standard 4KiB pages in 'Normal' zone) is to: - allocate 120000 pages for kernel's usage - free every second page (60000 pages) of memory just allocated - allocate and use 60000 pages from user space - free remaining 60000 pages of kernel memory (now we have fragmented memory occupied mostly by user space pages) - try to allocate 100 order-9 (2048 KiB) pages for kernel's usage The results: - with compaction disabled I get 11 successful allocations - with compaction enabled - 14 successful allocations - with this patch I'm able to get all 100 successful allocations I think above workload is really really artificial and theoretical so I didn't like this patch but Mel seem to like it. :( Quote from Mel " Ok, that is indeed an adverse workload that the current system will not properly deal with. I think you are right to try fixing this but may need a different approach that takes the cost out of the allocation/free path and moves it the compaction path." We can correct this patch to work but at least need justification about it. Do we really need this patch for such artificial workload? what do you think?
I'm ok to resubmit. But please change the thread. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>