On Fri, 30 Jan 2009 14:49:35 +0100 Ingo Molnar <mingo@xxxxxxx> wrote: > > So we still don't have any non-buggy proposal. > > Current upstream code is not pretty (due to the extra workqueue) but not > buggy either. You'd be right to point out that it is easy to insert a bug > into it and thus it's not pleasant (more of a workaround than a real fix) > but if it's outright buggy then please talk up. OK, so we're not aware of anything in there which will trigger the bug yet. Although allocate_threshold_blocks() takes about half the locks in the kernel - it can run an ext3 commit, it does netlink tx, synchronous process exec, etc. Why not give up and kill the whole work_on_cpu() thing? afaict the only caller which cannot be immediately switched to use an IPI is mce_amd_64's allocate_threshold_blocks(), and it looks like that can be trivially fixed by moving the entire function except for one rdmsr() up into the caller. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
