On Wed, 7 Jan 2009, Gregory Haskins wrote: > Hi Ingo, > > Ingo Molnar wrote: > > * Gregory Haskins <ghask...@novell.com> wrote: > > > > > >> Can I ask a simple question in light of all this discussion? > >> > >> "Is get_task_struct() really that bad?" > >> > > > > it dirties a cacheline and it also involves atomics. > > > Yes, understood. But we should note we are always going to be talking > about thrashing caches here since we are ultimately having one CPU > observe another. There's no way to get around that. I understand that > there are various degrees of this occurring, and I have no doubt that > the proposed improvements strive to achieve a reduction of that. My > question is really targeted at "at what cost". > > Don't get me wrong. I am not advocating going back to get/put-task per > se. I am simply asking the question of whether we have taken the design > off into the weeds having lost sight of the actual requirements and/or > results. Its starting to smell like we have. This is just a friendly > reality check. Feel free to disregard. ;)
What would be interesting is various benchmarks against all three. 1) no mutex spinning. 2) get_task_struct() implementation. 3) spin_or_sched implementation. I believe that 2 happens to be the easiest to understand. No need to know about the behavior of freed objects. If we see no or negligible improvement between 2 and 3 on any benchmark, then I say we stick with 2. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
