{"push_id":2722099250,"size":4,"distinct_size":4,"ref":"refs/heads/_RFC,v6,4_4__powerpc_fadump_Do_not_allow_hot-remove_memory_from_fadump_reserved_area__mbox_next","head":"24ba0df1f1d996c41d58ff69f9d22bf98440503a","before":"decc044122e2c8cf846db73a10d83637d4600012","commits":[{"sha":"14451f5d089e5e13e95c9c614a6394e7931b10c2","author":{"name":"Mahesh Salgaonkar","email":"6a890e1065a1d4e8df9dcf1d9a2c9c740bbcf8aa@linux.vnet.ibm.com"},"message":"mm/page_alloc: Introduce an interface to mark reserved memory as ZONE_MOVABLE\n\nAdd an interface to allow a custom reserved memory to be marked as\nZONE_MOVABLE. This will help some subsystem's to convert their reserved\nmemory region into ZONE_MOVABLE so that the memory can still be available\nto user applications.\n\nThe approach is based on Joonsoo Kim's commit bad8c6c0\n(https://github.com/torvalds/linux/commit/bad8c6c0) that\nuses ZONE_MOVABLE to manage CMA area. Majority of the code has been taken\nfrom the Joonsoo Kim's commit mentioned above. But I see above commit\nhas been reverted due to some issues reported on i386. I believe this\npatch is being reworked and re-posted soon.\n\nLike CMA, the other user of ZONE_MOVABLE can be fadump on powerpc, which\nreserves significant chunk of memory that is used only after system\nis crashed. Until then the reserved memory is unused. By marking that\nmemory to ZONE_MOVABLE, it can be at least utilized by user applications.\n\nThis patch proposes a RFC implementation of an interface to mark\nspecified reserved area as ZONE_MOVABLE. Comments are welcome.\n\nSigned-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/14451f5d089e5e13e95c9c614a6394e7931b10c2"},{"sha":"087fbc7047b5e9494c6503832679a0565e6d9fcf","author":{"name":"Mahesh Salgaonkar","email":"6a890e1065a1d4e8df9dcf1d9a2c9c740bbcf8aa@linux.vnet.ibm.com"},"message":"powerpc/fadump: Reservationless firmware assisted dump\n\nOne of the primary issues with Firmware Assisted Dump (fadump) on Power\nis that it needs a large amount of memory to be reserved. On large\nsystems with TeraBytes of memory, this reservation can be quite\nsignificant.\n\nIn some cases, fadump fails if the memory reserved is insufficient, or\nif the reserved memory was DLPAR hot-removed.\n\nIn the normal case, post reboot, the preserved memory is filtered to\nextract only relevant areas of interest using the makedumpfile tool.\nWhile the tool provides flexibility to determine what needs to be part\nof the dump and what memory to filter out, all supported distributions\ndefault this to \"Capture only kernel data and nothing else\".\n\nWe take advantage of this default and the Linux kernel's zone movable\nfeature to fundamentally change the memory reservation model for fadump.\n\nInstead of setting aside a significant chunk of memory nobody can use,\nthis patch marks a significant chunk of reserved memory as ZONE_MOVABLE\nthat the kernel is prevented from using (due to MIGRATE_MOVABLE),\nbut applications are free to use it. With this fadump will still be able\nto capture all of the kernel memory and most of the user space memory\nexcept the user pages that were present in ZONE_MOVABLE zone. But if\nsomeone wants to capture all of user space memory and ok with reserved\nmemory not available to production system, then 'fadump=nonmovable' kernel\nparameter can be used to fallback to old behaviour.\n\nEssentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:\n[root@zzxx-yy10 ~]# free -m\n              total        used        free      shared  buff/cache   available\nMem:           7557         193        6822          12         541        6725\nSwap:          4095           0        4095\n\nWith this patch:\n[root@zzxx-yy10 ~]# free -m\n              total        used        free      shared  buff/cache   available\nMem:           8133         194        7464          12         475        7338\nSwap:          4095           0        4095\n\nChanges made here are completely transparent to how fadump has\ntraditionally worked.\n\nSigned-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>\nSigned-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>\nSigned-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/087fbc7047b5e9494c6503832679a0565e6d9fcf"},{"sha":"a26507abd0fd0be699258566982f741e4acb39f9","author":{"name":"Mahesh Salgaonkar","email":"6a890e1065a1d4e8df9dcf1d9a2c9c740bbcf8aa@linux.vnet.ibm.com"},"message":"powerpc/fadump: throw proper error message on fadump registration failure.\n\nfadump fails to register when there are holes in reserved memory area.\nThis can happen if user has hot-removed a memory that falls in the fadump\nreserved memory area. Throw a meaningful error message to the user in\nsuch case.\n\nSigned-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/a26507abd0fd0be699258566982f741e4acb39f9"},{"sha":"24ba0df1f1d996c41d58ff69f9d22bf98440503a","author":{"name":"Mahesh Salgaonkar","email":"6a890e1065a1d4e8df9dcf1d9a2c9c740bbcf8aa@linux.vnet.ibm.com"},"message":"powerpc/fadump: Do not allow hot-remove memory from fadump reserved area.\n\nFor fadump to work successfully there should not be any holes in reserved\nmemory ranges where kernel has asked firmware to move the content of old\nkernel memory in event of crash. Now that fadump reserved memory is marked\nas movable zone, this memory area is now not protected from hot-remove\noperations. Hence, fadump service can fail to re-register after the\nhot-remove operation, if hot-removed memory belongs to fadump reserved\nregion. To avoid this make sure that memory from fadump reserved area is\nnot hot-removable if fadump is registered.\n\nHowever, if user still wants to remove that memory, he can do so by\nmanually stopping fadump service before hot-remove operation.\n\nSigned-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/24ba0df1f1d996c41d58ff69f9d22bf98440503a"}]}
{"actor":{"display_login":"ruscur"}}