From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [Patch] shm cleanups References: Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Christoph Rohland Date: 05 Nov 1999 11:36:34 +0100 In-Reply-To: Ingo Molnar's message of "Thu, 4 Nov 1999 23:30:01 +0100 (CET)" Message-ID: Sender: owner-linux-mm@kvack.org Return-Path: To: Ingo Molnar Cc: MM mailing list , woodman@missioncriticallinux.com, Linus Torvalds List-ID: Ingo Molnar writes: > On Thu, 4 Nov 1999, Rik van Riel wrote: > > > I think I see what is going on here. Kswapd sees that memory is > > low an "frees" a bunch of high memory pages, causing those pages > > to be shifted to low memory so the total number of free pages > > stays just as low as when kswapd started. > > hm, kswapd should really be immune against this. > > > This can result in in-memory swap storms, we should probably > > limit the number of in-transit async himem pages to 256 or some > > other even smaller number. > > i introduced some stupid balancing bugs, and i wrongly thought that the > fixes are already in 2.3.25, but no, it's the pre1-2.3.26 kernel that is > supposed to have balancing right. basically the fix is to restore the > original behavior of not counting high memory in memory pressure. This > might sound an unfair policy, but the real critical resource is low > memory. If this ever proves to be a problematic approach then we still can > make it more sophisticated. > > [Christoph, are you still seeing the same kind of bad swapping behavior > with pre1-2.3.26?] No, after applying the following patch, it is much better now: --- 2.3.26-pre/ipc/shm.c Fri Nov 5 10:25:40 1999 +++ make26/ipc/shm.c Fri Nov 5 10:54:09 1999 @@ -897,10 +897,10 @@ unlock_kernel(); return 0; } - if (page_count(page_map)) + if (page_count(page_map) != 1) goto check_table; if (!(page_map = prepare_highmem_swapout(page_map))) - goto check_table; + goto failed; SHM_ENTRY (shp, idx) = swp_entry_to_pte(swap_entry); swap_successes++; shm_swp++; [root@ls3016 src]# ipcs -um ------ Shared Memory Status -------- segments allocated 274 pages allocated 2244608 pages resident 2043405 pages swapped 177175 Swap performance: 251917 attempts 241439 successes [root@ls3016 src]# cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 4152516608 4133502976 19013632 0 512000 21954560 Swap: 4133269504 725725184 3407544320 MemTotal: 8249496 kB MemFree: 18568 kB MemShared: 0 kB Buffers: 500 kB Cached: 21440 kB HighTotal: 7471104 kB HighFree: 0 kB SwapTotal: 4036396 kB SwapFree: 3327680 kB and output of vmstat 5: procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 17 3 1 424020 2688 244 25932 407 10280 104 2570 970 1490 0 92 7 20 0 1 461380 1688 240 24464 467 8048 120 2012 758 1188 0 87 13 18 1 1 484676 27728 240 20692 994 5644 250 1411 549 910 0 90 10 19 0 1 497068 2732 260 25700 2690 5055 675 1264 532 1038 0 81 18 11 8 1 529820 4692 272 25192 4232 10643 1063 2661 1191 2126 0 85 15 17 2 1 559572 1472 264 19860 2538 8473 641 2118 919 1653 0 81 19 12 7 1 609780 1944 268 24280 3620 13611 912 3404 1485 2799 0 79 21 15 3 1 648148 1836 272 16648 8061 15666 2025 3916 2227 3731 0 78 22 12 6 1 692208 3044 280 23192 5394 14147 1359 3538 1768 3163 0 75 25 12 5 0 742160 2256 276 38144 6208 16190 1559 4047 1936 3419 0 78 22 So we have very few failes. Probably we never get caught by the second part of the above patch any more. > -- mingo > > ps. some people might ask why we want to swap on an 8GB box, but i think > it's really an issue in production systems to provide some kind of 'rubber > wall' instead of 'hard concrete' if the system is reaching its limits. > adding (99% unused) swap space does exactly this. Yes we need it for ERP applications. You do not beleive how many data is processed sometimes in business applications. And to have a hard limit for production servers is always a reason to use something else. Christoph -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://humbolt.geo.uu.nl/Linux-MM/