Prev: [PATCH v2] ath5k: disable ASPM
Next: [PATCH 1/3] hwmon: Driver for SMM665 Six-Channel Active DC Output Controller/Monitor
From: Andi Kleen on 19 Jun 2010 04:20 Michael Rubin <mrubin(a)google.com> writes: > > # cat /sys/block/sda/bdi/writeback_stats > balance dirty pages 0 > balance dirty pages waiting 0 > periodic writeback 92024 > periodic writeback exited 0 > laptop periodic 0 > laptop or bg threshold 0 > free more memory 0 > try to free pages 271 > syc_sync 6 > sync filesystem 0 That exports a lot of kernel internals in /sys, presumably read by some applications. What happens with the applications if the kernel internals ever change? Will the application break? It would be bad to not be able to change the kernel because of such an interface. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Rubin on 19 Jun 2010 14:00 Thanks for looking at this. On Sat, Jun 19, 2010 at 1:17 AM, Andi Kleen <andi(a)firstfloor.org> wrote: > Michael Rubin <mrubin(a)google.com> writes: >> � � # cat /sys/block/sda/bdi/writeback_stats >> � � balance dirty pages � � � � � � � � � � � 0 >> � � balance dirty pages waiting � � � � � � � 0 >> � � periodic writeback � � � � � � � � � �92024 >> � � periodic writeback exited � � � � � � � � 0 >> � � laptop periodic � � � � � � � � � � � � � 0 >> � � laptop or bg threshold � � � � � � � � � �0 >> � � free more memory � � � � � � � � � � � � �0 >> � � try to free pages � � � � � � � � � � � 271 >> � � syc_sync � � � � � � � � � � � � � � � � �6 >> � � sync filesystem � � � � � � � � � � � � � 0 > > That exports a lot of kernel internals in /sys, presumably read by some > applications. What happens with the applications if the kernel internals > ever change? �Will the application break? > > It would be bad to not be able to change the kernel because of > such an interface. 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. Are there alternatives to this? Maybe tracepoints that are compiled to be on? A CONFIG_WRITEBACK_DEBUG that would expose this file? 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. mrubin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 19 Jun 2010 16:30
Michael Rubin <mrubin(a)google.com> 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(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |