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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>