Messages in this thread |  | | Date | Mon, 19 Mar 2012 14:53:17 +0200 | | Subject | Re: seq_put_decimal_ull() et al | | From | Alexey Dobriyan <> |
| |
On Mon, Mar 19, 2012 at 3:29 AM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > (2012/03/16 20:16), Alexey Dobriyan wrote: > >> On Wed, Mar 14, 2012 at 5:08 AM, KAMEZAWA Hiroyuki >> <kamezawa.hiroyu@jp.fujitsu.com> wrote: >>> On Wed, 14 Mar 2012 09:31:56 +0900 >>> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: >>> >>>> On Tue, 13 Mar 2012 15:35:54 +0200 >>>> Alexey Dobriyan <adobriyan@gmail.com> wrote: >>>> >>>>>> Subject: + procfs-add-num_to_str-to-speed-up-proc-stat-fix-2.patch added to -mm tree >>>>> >>>>> I think the fix is to create proper binary interface for exporting >>>>> interrupt counts. >>>>> Programs can parse raw data equally well if programming language is >>>>> even minimally reasonable >>>>> (POSIX shell may not qualify, though). >>>> >>>> Ok, please try with all tool-chain updates. >>>> procps, top, sar, and more ? >>>> >> >> Well, why not? >> We can tune print code or we can create maximally fast interface and forget. >> > > Do you have an idea where to place it ? > /proc/stat_binary ? > /proc/binary/stat ? > > Hm, to parse /proc/stat binary format, the user has to know the format of the > kernel version. > > Do we show a format file as > /proc/binary/stat_format and show > # cat /proc/binary/stat_format > =IHHHIHIQQQIHQQ... > > as python's pack/unpack ? or > export the format via /usr/include/linux/proc_format.h ? as a structure ? > > any better idea ?
I'm thinking of separate file with interrupts statistics. Let's not mix everything. Hmm, let me see how top(1) parses /proc/interrupts. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |