diff for duplicates of <480EDD2F.BA47.005A.0@novell.com> diff --git a/a/1.txt b/N1/1.txt index 7efab78..e50f6e7 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -42,8 +42,7 @@ No it doesn't, but I don't see that as a requirement to work properly. All we r > task_wake_up_rt() will see the NEED_RESCHED flag and bail out while it > would make sense at this moment to push T1 off this cpu. -I think this is "ok". IMO, we really want to prioritize the push operation from post_schedule() over task_wake_up() because it is the most accurate (since the scheduling decision would be atomic to the rq->lock). This way we avoid pushing the wrong task away before the schedule has a chance to run. I think your alg probably approximates this same accuracy, albeit in a more expensive way. The one thing I can say is an advantage to your approach is that it potentially would migrate the task faster (though it shouldn't be by very much, since the resched is technically pending). This argument is further compounded by the fact that you would have to subtract the extra overhead of running pick_next_task() et. al. from the gain of avoiding the wait for the reschedule, of course. This would - errode some of the lower-latency argument. +I think this is "ok". IMO, we really want to prioritize the push operation from post_schedule() over task_wake_up() because it is the most accurate (since the scheduling decision would be atomic to the rq->lock). This way we avoid pushing the wrong task away before the schedule has a chance to run. I think your alg probably approximates this same accuracy, albeit in a more expensive way. The one thing I can say is an advantage to your approach is that it potentially would migrate the task faster (though it shouldn't be by very much, since the resched is technically pending). This argument is further compounded by the fact that you would have to subtract the extra overhead of running pick_next_task() et. al. from the gain of avoiding the wait for the reschedule, of course. This would errode some of the lower-latency argument. Hmmm... Im not sure which I like better...simplicity is often nice IMO, but I think either could work. diff --git a/a/content_digest b/N1/content_digest index 5964c91..38f31f7 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -64,8 +64,7 @@ "> task_wake_up_rt() will see the NEED_RESCHED flag and bail out while it\n" "> would make sense at this moment to push T1 off this cpu.\n" "\n" - "I think this is \"ok\". IMO, we really want to prioritize the push operation from post_schedule() over task_wake_up() because it is the most accurate (since the scheduling decision would be atomic to the rq->lock). This way we avoid pushing the wrong task away before the schedule has a chance to run. I think your alg probably approximates this same accuracy, albeit in a more expensive way. The one thing I can say is an advantage to your approach is that it potentially would migrate the task faster (though it shouldn't be by very much, since the resched is technically pending). This argument is further compounded by the fact that you would have to subtract the extra overhead of running pick_next_task() et. al. from the gain of avoiding the wait for the reschedule, of course. This would \n" - " errode some of the lower-latency argument.\n" + "I think this is \"ok\". IMO, we really want to prioritize the push operation from post_schedule() over task_wake_up() because it is the most accurate (since the scheduling decision would be atomic to the rq->lock). This way we avoid pushing the wrong task away before the schedule has a chance to run. I think your alg probably approximates this same accuracy, albeit in a more expensive way. The one thing I can say is an advantage to your approach is that it potentially would migrate the task faster (though it shouldn't be by very much, since the resched is technically pending). This argument is further compounded by the fact that you would have to subtract the extra overhead of running pick_next_task() et. al. from the gain of avoiding the wait for the reschedule, of course. This would errode some of the lower-latency argument.\n" "\n" "Hmmm... Im not sure which I like better...simplicity is often nice IMO, but I think either could work.\n" "\n" @@ -77,4 +76,4 @@ "\n" > -11a024a0a70a56e84f06788ed2e2fcd7897c611c628115584a1fbeddbef4779c +ac0a9d85ab39290bd493e9f0865f1e4debcac87942c60a5c357fd12094d868cc
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.