Michael Rubin <mrubin@xxxxxxxxxx> writes: > > I agree. This would put the kernel in a box a bit. Some of them > (sys_sync, periodic writeback, free_more_memory) I feel are generic > enough concepts that with some rewording of the labels they could be > exposed with no issue. "Balance_dirty_pages" is an example where that > won't work. Yes some rewording would be good. > Are there alternatives to this? Maybe tracepoints that are compiled to be on? > A CONFIG_WRITEBACK_DEBUG that would expose this file? The classic way is to put it into debugfs which has a appropiate disclaimer. (although I fear we're weaning apps that depend on debugfs too The growing ftrace user space code seems to all depend on debugfs) > Having this set of info readily available and collected makes > debugging a lot easier. But I admit I am not sure the best way to > expose them. Maybe we just need a simpler writeback path that is not as complicated to debug. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
