From: Andi Kleen on
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
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
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/