{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":193520156,"defaultBranch":"linux-5.10","name":"simple_lmk","ownerLogin":"kerneltoast","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2019-06-24T14:21:03.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2985099?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1683172952.0","currentOid":""},"activityList":{"items":[{"before":"4ea26417d2a491650f32fc584adfbfd36070cf97","after":"2227fbe48c70ad67324910e6517a166a9e7be4f0","ref":"refs/heads/linux-4.14","pushedAt":"2023-10-04T03:54:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"mm: Always indicate OOM kill progress when Simple LMK is enabled\n\nWhen Simple LMK is enabled, the page allocator slowpath always thinks that\nno OOM kill progress is made because out_of_memory() returns false. As a\nresult, spurious page allocation failures are observed when memory is low\nand Simple LMK is killing tasks, simply because the page allocator slowpath\ndoesn't think that any OOM killing is taking place.\n\nFix this by simply making out_of_memory() always return true when Simple\nLMK is enabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"mm: Always indicate OOM kill progress when Simple LMK is enabled"}},{"before":"9d590c73bed2c193b53e4076a4ecc7db266fe466","after":"2bfc56f8048c67c5118ac9111752a08279855ea8","ref":"refs/heads/linux-5.10","pushedAt":"2023-10-04T03:54:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"mm: Always indicate OOM kill progress when Simple LMK is enabled\n\nWhen Simple LMK is enabled, the page allocator slowpath always thinks that\nno OOM kill progress is made because out_of_memory() returns false. As a\nresult, spurious page allocation failures are observed when memory is low\nand Simple LMK is killing tasks, simply because the page allocator slowpath\ndoesn't think that any OOM killing is taking place.\n\nFix this by simply making out_of_memory() always return true when Simple\nLMK is enabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"mm: Always indicate OOM kill progress when Simple LMK is enabled"}},{"before":"a912f805e482aaebd26fb170cdaea9238b2441d0","after":"5f8cd87e4c935053d2a56fcf4130550198447309","ref":"refs/heads/linux-4.4","pushedAt":"2023-10-04T03:54:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"mm: Always indicate OOM kill progress when Simple LMK is enabled\n\nWhen Simple LMK is enabled, the page allocator slowpath always thinks that\nno OOM kill progress is made because out_of_memory() returns false. As a\nresult, spurious page allocation failures are observed when memory is low\nand Simple LMK is killing tasks, simply because the page allocator slowpath\ndoesn't think that any OOM killing is taking place.\n\nFix this by simply making out_of_memory() always return true when Simple\nLMK is enabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"mm: Always indicate OOM kill progress when Simple LMK is enabled"}},{"before":"2027484d8a2e954278068d3dc107741adf19d32f","after":"71e9b8150be014d87a87277018487cc7547dc506","ref":"refs/heads/linux-4.9","pushedAt":"2023-10-04T03:54:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"mm: Always indicate OOM kill progress when Simple LMK is enabled\n\nWhen Simple LMK is enabled, the page allocator slowpath always thinks that\nno OOM kill progress is made because out_of_memory() returns false. As a\nresult, spurious page allocation failures are observed when memory is low\nand Simple LMK is killing tasks, simply because the page allocator slowpath\ndoesn't think that any OOM killing is taking place.\n\nFix this by simply making out_of_memory() always return true when Simple\nLMK is enabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"mm: Always indicate OOM kill progress when Simple LMK is enabled"}},{"before":"8743ae5a4a1e1f7a49b25b9894f078d8274c53dc","after":"77d64863e6f56c3acf522d43a2f90aa67e9785c4","ref":"refs/heads/linux-4.19","pushedAt":"2023-10-04T03:54:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"mm: Always indicate OOM kill progress when Simple LMK is enabled\n\nWhen Simple LMK is enabled, the page allocator slowpath always thinks that\nno OOM kill progress is made because out_of_memory() returns false. As a\nresult, spurious page allocation failures are observed when memory is low\nand Simple LMK is killing tasks, simply because the page allocator slowpath\ndoesn't think that any OOM killing is taking place.\n\nFix this by simply making out_of_memory() always return true when Simple\nLMK is enabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"mm: Always indicate OOM kill progress when Simple LMK is enabled"}},{"before":"139c22ff25bca4aa53edb9ea0c591e5137a72b3a","after":"c2530f70c8f259aecf9db3e34f8df2a1ee92d6a6","ref":"refs/heads/linux-5.4","pushedAt":"2023-10-04T03:54:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"mm: Always indicate OOM kill progress when Simple LMK is enabled\n\nWhen Simple LMK is enabled, the page allocator slowpath always thinks that\nno OOM kill progress is made because out_of_memory() returns false. As a\nresult, spurious page allocation failures are observed when memory is low\nand Simple LMK is killing tasks, simply because the page allocator slowpath\ndoesn't think that any OOM killing is taking place.\n\nFix this by simply making out_of_memory() always return true when Simple\nLMK is enabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"mm: Always indicate OOM kill progress when Simple LMK is enabled"}},{"before":"4bbb8340aba20dc8b99520116fadd20de0d20279","after":"139c22ff25bca4aa53edb9ea0c591e5137a72b3a","ref":"refs/heads/linux-5.4","pushedAt":"2023-05-15T04:12:02.316Z","pushType":"push","commitsCount":3,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Reap anonymous memory from victims\n\nThe OOM reaper makes it possible to immediately release anonymous memory\nfrom a dying process in order to free up memory faster. This provides\nimmediate relief under heavy memory pressure instead of waiting for victim\nprocesses to naturally release their memory.\n\nUtilize the OOM reaper by creating another kthread in Simple LMK to perform\nvictim reaping. Similar to the OOM reaper kthread (which is unused with\nSimple LMK), this new kthread allows reaping to race with exit_mmap() in\norder to preclude the need to take a reference to an mm's address space and\nthus potentially mmput() an mm's last reference. Doing so would stall the\nreaper kthread, preventing it from being able to quickly reap new victims.\n\nReaping is done on victims one at a time by descending order of anonymous\npages, so that the most promising victims with the most anonymous pages\nare reaped first. Victims are also marked for reaping via MMF_OOM_VICTIM so\nthat they reap themselves first in exit_mmap(). Even if a victim isn't\nreaped by the reaper thread, it'll free its anonymous memory first thing in\nexit_mmap() as a small win towards making memory available sooner.\n\nBy relieving memory pressure faster via reaping, Simple LMK not only\ndoesn't need to kill as many processes, but also improves system\nresponsiveness when memory is low since memory pressure is relieved sooner.\n\nAlthough not strictly required, Simple LMK should be the only one utilizing\nthe OOM reaper. Any other code that may utilize the OOM reaper, such as\npatches that invoke the OOM reaper for all SIGKILLs, should be disabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Reap anonymous memory from victims"}},{"before":"99bd60098515766e18ea1d7efba2c396fabb7205","after":"2027484d8a2e954278068d3dc107741adf19d32f","ref":"refs/heads/linux-4.9","pushedAt":"2023-05-15T04:12:02.316Z","pushType":"push","commitsCount":2,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Reduce unnecessary wake ups\n\nWe can check if the waitqueue is actually active before calling wake_up()\nin order to avoid an unnecessary wake_up() if the reclaim thread is already\nrunning. Furthermore, the release barrier when zeroing needs_reclaim is\nunnecessary, so remove it.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Reduce unnecessary wake ups"}},{"before":"6b188619730244466c3e802c531286c78aeabd19","after":"4ea26417d2a491650f32fc584adfbfd36070cf97","ref":"refs/heads/linux-4.14","pushedAt":"2023-05-15T04:12:02.316Z","pushType":"push","commitsCount":3,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Reap anonymous memory from victims\n\nThe OOM reaper makes it possible to immediately release anonymous memory\nfrom a dying process in order to free up memory faster. This provides\nimmediate relief under heavy memory pressure instead of waiting for victim\nprocesses to naturally release their memory.\n\nUtilize the OOM reaper by creating another kthread in Simple LMK to perform\nvictim reaping. Similar to the OOM reaper kthread (which is unused with\nSimple LMK), this new kthread allows reaping to race with exit_mmap() in\norder to preclude the need to take a reference to an mm's address space and\nthus potentially mmput() an mm's last reference. Doing so would stall the\nreaper kthread, preventing it from being able to quickly reap new victims.\n\nReaping is done on victims one at a time by descending order of anonymous\npages, so that the most promising victims with the most anonymous pages\nare reaped first. Victims are also marked for reaping via MMF_OOM_VICTIM so\nthat they reap themselves first in exit_mmap(). Even if a victim isn't\nreaped by the reaper thread, it'll free its anonymous memory first thing in\nexit_mmap() as a small win towards making memory available sooner.\n\nBy relieving memory pressure faster via reaping, Simple LMK not only\ndoesn't need to kill as many processes, but also improves system\nresponsiveness when memory is low since memory pressure is relieved sooner.\n\nAlthough not strictly required, Simple LMK should be the only one utilizing\nthe OOM reaper. Any other code that may utilize the OOM reaper, such as\npatches that invoke the OOM reaper for all SIGKILLs, should be disabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Reap anonymous memory from victims"}},{"before":"998373b5e177d372b0a200a93eaab4470f76dfd2","after":"8743ae5a4a1e1f7a49b25b9894f078d8274c53dc","ref":"refs/heads/linux-4.19","pushedAt":"2023-05-15T04:12:02.316Z","pushType":"push","commitsCount":3,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Reap anonymous memory from victims\n\nThe OOM reaper makes it possible to immediately release anonymous memory\nfrom a dying process in order to free up memory faster. This provides\nimmediate relief under heavy memory pressure instead of waiting for victim\nprocesses to naturally release their memory.\n\nUtilize the OOM reaper by creating another kthread in Simple LMK to perform\nvictim reaping. Similar to the OOM reaper kthread (which is unused with\nSimple LMK), this new kthread allows reaping to race with exit_mmap() in\norder to preclude the need to take a reference to an mm's address space and\nthus potentially mmput() an mm's last reference. Doing so would stall the\nreaper kthread, preventing it from being able to quickly reap new victims.\n\nReaping is done on victims one at a time by descending order of anonymous\npages, so that the most promising victims with the most anonymous pages\nare reaped first. Victims are also marked for reaping via MMF_OOM_VICTIM so\nthat they reap themselves first in exit_mmap(). Even if a victim isn't\nreaped by the reaper thread, it'll free its anonymous memory first thing in\nexit_mmap() as a small win towards making memory available sooner.\n\nBy relieving memory pressure faster via reaping, Simple LMK not only\ndoesn't need to kill as many processes, but also improves system\nresponsiveness when memory is low since memory pressure is relieved sooner.\n\nAlthough not strictly required, Simple LMK should be the only one utilizing\nthe OOM reaper. Any other code that may utilize the OOM reaper, such as\npatches that invoke the OOM reaper for all SIGKILLs, should be disabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Reap anonymous memory from victims"}},{"before":"69052d92113cbfbbfdc66da79763434f9a15660e","after":"9d590c73bed2c193b53e4076a4ecc7db266fe466","ref":"refs/heads/linux-5.10","pushedAt":"2023-05-15T04:12:02.316Z","pushType":"push","commitsCount":3,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Reap anonymous memory from victims\n\nThe OOM reaper makes it possible to immediately release anonymous memory\nfrom a dying process in order to free up memory faster. This provides\nimmediate relief under heavy memory pressure instead of waiting for victim\nprocesses to naturally release their memory.\n\nUtilize the OOM reaper by creating another kthread in Simple LMK to perform\nvictim reaping. Similar to the OOM reaper kthread (which is unused with\nSimple LMK), this new kthread allows reaping to race with exit_mmap() in\norder to preclude the need to take a reference to an mm's address space and\nthus potentially mmput() an mm's last reference. Doing so would stall the\nreaper kthread, preventing it from being able to quickly reap new victims.\n\nReaping is done on victims one at a time by descending order of anonymous\npages, so that the most promising victims with the most anonymous pages\nare reaped first. Victims are also marked for reaping via MMF_OOM_VICTIM so\nthat they reap themselves first in exit_mmap(). Even if a victim isn't\nreaped by the reaper thread, it'll free its anonymous memory first thing in\nexit_mmap() as a small win towards making memory available sooner.\n\nBy relieving memory pressure faster via reaping, Simple LMK not only\ndoesn't need to kill as many processes, but also improves system\nresponsiveness when memory is low since memory pressure is relieved sooner.\n\nAlthough not strictly required, Simple LMK should be the only one utilizing\nthe OOM reaper. Any other code that may utilize the OOM reaper, such as\npatches that invoke the OOM reaper for all SIGKILLs, should be disabled.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Reap anonymous memory from victims"}},{"before":"32c44916e25276413d16b0d028e75915d7c0b293","after":"a912f805e482aaebd26fb170cdaea9238b2441d0","ref":"refs/heads/linux-4.4","pushedAt":"2023-05-15T04:12:02.316Z","pushType":"push","commitsCount":2,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Reduce unnecessary wake ups\n\nWe can check if the waitqueue is actually active before calling wake_up()\nin order to avoid an unnecessary wake_up() if the reclaim thread is already\nrunning. Furthermore, the release barrier when zeroing needs_reclaim is\nunnecessary, so remove it.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Reduce unnecessary wake ups"}},{"before":"47372d03af598383ef10d1ea70e4945d3f86af6c","after":"4bbb8340aba20dc8b99520116fadd20de0d20279","ref":"refs/heads/linux-5.4","pushedAt":"2023-05-05T23:51:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Fix victim scheduling priority elevation\n\nAs it turns out, victim scheduling priority elevation has always been\nbroken for two reasons:\n1. The minimum valid RT priority is 1, not 0. As a result,\n   sched_setscheduler_nocheck() always fails with -EINVAL.\n2. The thread within a victim thread group which happens to hold the mm is\n   not necessarily the only thread with references to the mm, and isn't\n   necessarily the thread which will release the final mm reference. As a\n   result, victim threads which hold mm references may take a while to\n   release them, and the unlucky thread which puts the final mm reference\n   may take a very long time to release all memory if it doesn't have RT\n   scheduling priority.\n\nThese issues cause victims to often take a very long time to release their\nmemory, possibly up to several seconds depending on system load. This, in\nturn, causes Simple LMK to constantly hit the reclaim timeout and kill more\nprocesses, with Simple LMK being rather ineffective since victims may not\nrelease any memory for several seconds.\n\nFix the broken scheduling priority elevation by changing the RT priority to\nthe valid lowest priority of 1 and applying it to all threads in the thread\ngroup, instead of just the thread which holds the mm.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Fix victim scheduling priority elevation"}},{"before":"b71ad8db9f5029cba711972b9e50de59a7a0bef1","after":"998373b5e177d372b0a200a93eaab4470f76dfd2","ref":"refs/heads/linux-4.19","pushedAt":"2023-05-05T23:51:02.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Fix victim scheduling priority elevation\n\nAs it turns out, victim scheduling priority elevation has always been\nbroken for two reasons:\n1. The minimum valid RT priority is 1, not 0. As a result,\n   sched_setscheduler_nocheck() always fails with -EINVAL.\n2. The thread within a victim thread group which happens to hold the mm is\n   not necessarily the only thread with references to the mm, and isn't\n   necessarily the thread which will release the final mm reference. As a\n   result, victim threads which hold mm references may take a while to\n   release them, and the unlucky thread which puts the final mm reference\n   may take a very long time to release all memory if it doesn't have RT\n   scheduling priority.\n\nThese issues cause victims to often take a very long time to release their\nmemory, possibly up to several seconds depending on system load. This, in\nturn, causes Simple LMK to constantly hit the reclaim timeout and kill more\nprocesses, with Simple LMK being rather ineffective since victims may not\nrelease any memory for several seconds.\n\nFix the broken scheduling priority elevation by changing the RT priority to\nthe valid lowest priority of 1 and applying it to all threads in the thread\ngroup, instead of just the thread which holds the mm.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Fix victim scheduling priority elevation"}},{"before":"f46b5fd3abc41586efc399118e37082ad837418e","after":"6b188619730244466c3e802c531286c78aeabd19","ref":"refs/heads/linux-4.14","pushedAt":"2023-05-05T23:50:58.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Fix victim scheduling priority elevation\n\nAs it turns out, victim scheduling priority elevation has always been\nbroken for two reasons:\n1. The minimum valid RT priority is 1, not 0. As a result,\n   sched_setscheduler_nocheck() always fails with -EINVAL.\n2. The thread within a victim thread group which happens to hold the mm is\n   not necessarily the only thread with references to the mm, and isn't\n   necessarily the thread which will release the final mm reference. As a\n   result, victim threads which hold mm references may take a while to\n   release them, and the unlucky thread which puts the final mm reference\n   may take a very long time to release all memory if it doesn't have RT\n   scheduling priority.\n\nThese issues cause victims to often take a very long time to release their\nmemory, possibly up to several seconds depending on system load. This, in\nturn, causes Simple LMK to constantly hit the reclaim timeout and kill more\nprocesses, with Simple LMK being rather ineffective since victims may not\nrelease any memory for several seconds.\n\nFix the broken scheduling priority elevation by changing the RT priority to\nthe valid lowest priority of 1 and applying it to all threads in the thread\ngroup, instead of just the thread which holds the mm.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Fix victim scheduling priority elevation"}},{"before":"dd494696b3a7917a6cef4f5d471e68bee22e7595","after":"99bd60098515766e18ea1d7efba2c396fabb7205","ref":"refs/heads/linux-4.9","pushedAt":"2023-05-05T23:50:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Fix victim scheduling priority elevation\n\nAs it turns out, victim scheduling priority elevation has always been\nbroken for two reasons:\n1. The minimum valid RT priority is 1, not 0. As a result,\n   sched_setscheduler_nocheck() always fails with -EINVAL.\n2. The thread within a victim thread group which happens to hold the mm is\n   not necessarily the only thread with references to the mm, and isn't\n   necessarily the thread which will release the final mm reference. As a\n   result, victim threads which hold mm references may take a while to\n   release them, and the unlucky thread which puts the final mm reference\n   may take a very long time to release all memory if it doesn't have RT\n   scheduling priority.\n\nThese issues cause victims to often take a very long time to release their\nmemory, possibly up to several seconds depending on system load. This, in\nturn, causes Simple LMK to constantly hit the reclaim timeout and kill more\nprocesses, with Simple LMK being rather ineffective since victims may not\nrelease any memory for several seconds.\n\nFix the broken scheduling priority elevation by changing the RT priority to\nthe valid lowest priority of 1 and applying it to all threads in the thread\ngroup, instead of just the thread which holds the mm.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Fix victim scheduling priority elevation"}},{"before":"93b0b623bb80fd00bec44a61b846a3a98be409da","after":"32c44916e25276413d16b0d028e75915d7c0b293","ref":"refs/heads/linux-4.4","pushedAt":"2023-05-05T23:50:50.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Fix victim scheduling priority elevation\n\nAs it turns out, victim scheduling priority elevation has always been\nbroken for two reasons:\n1. The minimum valid RT priority is 1, not 0. As a result,\n   sched_setscheduler_nocheck() always fails with -EINVAL.\n2. The thread within a victim thread group which happens to hold the mm is\n   not necessarily the only thread with references to the mm, and isn't\n   necessarily the thread which will release the final mm reference. As a\n   result, victim threads which hold mm references may take a while to\n   release them, and the unlucky thread which puts the final mm reference\n   may take a very long time to release all memory if it doesn't have RT\n   scheduling priority.\n\nThese issues cause victims to often take a very long time to release their\nmemory, possibly up to several seconds depending on system load. This, in\nturn, causes Simple LMK to constantly hit the reclaim timeout and kill more\nprocesses, with Simple LMK being rather ineffective since victims may not\nrelease any memory for several seconds.\n\nFix the broken scheduling priority elevation by changing the RT priority to\nthe valid lowest priority of 1 and applying it to all threads in the thread\ngroup, instead of just the thread which holds the mm.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Fix victim scheduling priority elevation"}},{"before":"78c584a1c689c4b05b3bc546e4558bd2b9caac21","after":"69052d92113cbfbbfdc66da79763434f9a15660e","ref":"refs/heads/linux-5.10","pushedAt":"2023-05-05T23:50:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Fix victim scheduling priority elevation\n\nAs it turns out, victim scheduling priority elevation has always been\nbroken for two reasons:\n1. The minimum valid RT priority is 1, not 0. As a result,\n   sched_setscheduler_nocheck() always fails with -EINVAL.\n2. The thread within a victim thread group which happens to hold the mm is\n   not necessarily the only thread with references to the mm, and isn't\n   necessarily the thread which will release the final mm reference. As a\n   result, victim threads which hold mm references may take a while to\n   release them, and the unlucky thread which puts the final mm reference\n   may take a very long time to release all memory if it doesn't have RT\n   scheduling priority.\n\nThese issues cause victims to often take a very long time to release their\nmemory, possibly up to several seconds depending on system load. This, in\nturn, causes Simple LMK to constantly hit the reclaim timeout and kill more\nprocesses, with Simple LMK being rather ineffective since victims may not\nrelease any memory for several seconds.\n\nFix the broken scheduling priority elevation by changing the RT priority to\nthe valid lowest priority of 1 and applying it to all threads in the thread\ngroup, instead of just the thread which holds the mm.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Fix victim scheduling priority elevation"}},{"before":null,"after":"78c584a1c689c4b05b3bc546e4558bd2b9caac21","ref":"refs/heads/linux-5.10","pushedAt":"2023-05-04T04:02:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"kerneltoast","name":"Sultan Alsawaf","path":"/kerneltoast","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2985099?s=80&v=4"},"commit":{"message":"simple_lmk: Thaw victims upon killing them\n\nWith freezable cgroups and their recent utilization in Android, it's\npossible for some of Simple LMK's victims to be frozen at the time that\nthey're selected for killing. The forced SIGKILL used for killing\nvictims can only wake up processes containing TASK_WAKEKILL and/or\nTASK_INTERRUPTIBLE, not TASK_UNINTERRUPTIBLE, which is the state used on\nfrozen tasks. In order to wake frozen tasks from their uninterruptible\nslumber so that they can die, we must thaw them. Leaving victims frozen\ncan otherwise make them take an indefinite amount of time to process our\nSIGKILL and thus free memory.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","shortMessageHtmlLink":"simple_lmk: Thaw victims upon killing them"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAADjtz2TAA","startCursor":null,"endCursor":null}},"title":"Activity · kerneltoast/simple_lmk"}