Re: [PATCH 1/2] Support PCU power metrics in turbostat
On Tue, Mar 24, 2015 at 05:20:13PM -0400, Len Brown wrote: > > > On Thu, Nov 13, 2014 at 6:19 PM, Andi Kleen wrote: > > From: Andi Kleen > > > > Add support for reading PCU power metrics on Sandy Bridge / Ivy Bridge EP > > and Haswell Server in turbostat. This is done using the perf ABI, > > using the perf uncore driver. This requires the kernel to > > have uncore perf driver support. > > What happens if kernel doesn't include that support? The data is not displayed. > > The user has to specify the event group using a new -x option. All > > more sensible option characters were already taken. When -x is > > not specified no behavior changes. > > I'm concerned that turbostat cmdline is getting too complicated, > and this makes that more the case. Modern computers are complicated. No way around it. > > However this currently runs into a problem with the uncore > > driver that only makes us able to monitor a single band. > > Disabled until this is fixed. BTW this is fixed. Will update. > > Custom user metrics would be also possible. > > > > The event resolution code is derived from the jevents library > > (parts of pmu-tools, http://github.com/andikleen/pmu-tools) > > and is BSD licensed. > > can we put BSD licensed code into utilities that are in the linux > kernel git tree? I think so. There are already some. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Support PCU power metrics in turbostat
On Thu, Nov 13, 2014 at 6:19 PM, Andi Kleen wrote: > From: Andi Kleen > > Add support for reading PCU power metrics on Sandy Bridge / Ivy Bridge EP > and Haswell Server in turbostat. This is done using the perf ABI, > using the perf uncore driver. This requires the kernel to > have uncore perf driver support. What happens if kernel doesn't include that support? > The PCU has a large number of events, but only allows to monitor > four of them at the same time. We always need the PCU cycles > event, so this leaves three events per event group. > > The user has to specify the event group using a new -x option. All > more sensible option characters were already taken. When -x is > not specified no behavior changes. I'm concerned that turbostat cmdline is getting too complicated, and this makes that more the case. would need EXAMPLES in turbostat.8 to really be useful. > perf in principle supports time based multi-plexing, which > allows monitoring multiple group at the same time, but support for > that is not implemented in the tool so far. It would > also require enabling an potentially idle-disturbing timer. > So right now we don't multiplex. > > I modeled the event groups after the proven ones in > pcm-power in the PCM (Intel Performance Counter Monitor) tool. > That is where the numbers come from. > > However unlike PCM this uses the perf interfaces, instead > of directly accessing the hardware. > > The current groups are: > > 0: This should 3 monitor frequency bands. It could give more > accurate information than the average frequency from turbostat, > as it can keep multiple buckets. > > However this currently runs into a problem with the uncore > driver that only makes us able to monitor a single band. > Disabled until this is fixed. > > 1: C-state residencies. Already covered in turbostat and not > implemented. > > 2/3/4: Various reasons for frequency limits. > > 5: Number of frequency transitions and time of PCU transition duration. > (note this is not the full time of the transition) > > Other power metrics could be added later using the same frame work. > For example it would be possible to implement the memory power saving > metrics from pcm-power, which would output power state statistics per > channel. This would definitely need a new output format, > as it won't fit into any terminal with the current one. More columns are no longer an issue. The latest turbostat has two modes -- default is just topology & frequency. The --debug option adds all metrics, and output is generally re-directed to a file. > > Custom user metrics would be also possible. > > The event resolution code is derived from the jevents library > (parts of pmu-tools, http://github.com/andikleen/pmu-tools) > and is BSD licensed. can we put BSD licensed code into utilities that are in the linux kernel git tree? I sort of like a single source file, but if the code really is unrelated, I guess 2nd file is okay. thanks, -Len > Signed-off-by: Andi Kleen > --- > tools/power/x86/turbostat/Makefile| 11 +- > tools/power/x86/turbostat/resolve.c | 233 > ++ > tools/power/x86/turbostat/resolve.h | 2 + > tools/power/x86/turbostat/turbostat.8 | 5 + > tools/power/x86/turbostat/turbostat.c | 206 +- > 5 files changed, 449 insertions(+), 8 deletions(-) > create mode 100644 tools/power/x86/turbostat/resolve.c > create mode 100644 tools/power/x86/turbostat/resolve.h > > diff --git a/tools/power/x86/turbostat/Makefile > b/tools/power/x86/turbostat/Makefile > index d1b3a36..745af06 100644 > --- a/tools/power/x86/turbostat/Makefile > +++ b/tools/power/x86/turbostat/Makefile > @@ -3,17 +3,20 @@ BUILD_OUTPUT := $(PWD) > PREFIX := /usr > DESTDIR:= > > -turbostat : turbostat.c > +turbostat : turbostat.o resolve.o > + @mkdir -p $(BUILD_OUTPUT) > + $(CC) $(LDFLAGS) $^ -o $(BUILD_OUTPUT)/$@ > + > CFLAGS += -Wall > CFLAGS += > -DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"' > > -%: %.c > +%.o: %.c > @mkdir -p $(BUILD_OUTPUT) > - $(CC) $(CFLAGS) $< -o $(BUILD_OUTPUT)/$@ > + $(CC) $(CFLAGS) $< -c -o $(BUILD_OUTPUT)/$@ > > .PHONY : clean > clean : > - @rm -f $(BUILD_OUTPUT)/turbostat > + @rm -f $(BUILD_OUTPUT)/turbostat turbostat.o resolve.o > > install : turbostat > install -d $(DESTDIR)$(PREFIX)/bin > diff --git a/tools/power/x86/turbostat/resolve.c > b/tools/power/x86/turbostat/resolve.c > new file mode 100644 > index 000..ad53159 > --- /dev/null > +++ b/tools/power/x86/turbostat/resolve.c > @@ -0,0 +1,233 @@ > +/* Resolve perf style event descriptions to attr */ > +/* > + * Copyright (c) 2014, Intel Corporation > + * Author: Andi Kleen > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions are > met: > + * > + * 1. Redistr
[PATCH 1/2] Support PCU power metrics in turbostat
From: Andi Kleen Add support for reading PCU power metrics on Sandy Bridge / Ivy Bridge EP and Haswell Server in turbostat. This is done using the perf ABI, using the perf uncore driver. This requires the kernel to have uncore perf driver support. The PCU has a large number of events, but only allows to monitor four of them at the same time. We always need the PCU cycles event, so this leaves three events per event group. The user has to specify the event group using a new -x option. All more sensible option characters were already taken. When -x is not specified no behavior changes. perf in principle supports time based multi-plexing, which allows monitoring multiple group at the same time, but support for that is not implemented in the tool so far. It would also require enabling an potentially idle-disturbing timer. So right now we don't multiplex. I modeled the event groups after the proven ones in pcm-power in the PCM (Intel Performance Counter Monitor) tool. That is where the numbers come from. However unlike PCM this uses the perf interfaces, instead of directly accessing the hardware. The current groups are: 0: This should 3 monitor frequency bands. It could give more accurate information than the average frequency from turbostat, as it can keep multiple buckets. However this currently runs into a problem with the uncore driver that only makes us able to monitor a single band. Disabled until this is fixed. 1: C-state residencies. Already covered in turbostat and not implemented. 2/3/4: Various reasons for frequency limits. 5: Number of frequency transitions and time of PCU transition duration. (note this is not the full time of the transition) Other power metrics could be added later using the same frame work. For example it would be possible to implement the memory power saving metrics from pcm-power, which would output power state statistics per channel. This would definitely need a new output format, as it won't fit into any terminal with the current one. Custom user metrics would be also possible. The event resolution code is derived from the jevents library (parts of pmu-tools, http://github.com/andikleen/pmu-tools) and is BSD licensed. Signed-off-by: Andi Kleen --- tools/power/x86/turbostat/Makefile| 11 +- tools/power/x86/turbostat/resolve.c | 233 ++ tools/power/x86/turbostat/resolve.h | 2 + tools/power/x86/turbostat/turbostat.8 | 5 + tools/power/x86/turbostat/turbostat.c | 206 +- 5 files changed, 449 insertions(+), 8 deletions(-) create mode 100644 tools/power/x86/turbostat/resolve.c create mode 100644 tools/power/x86/turbostat/resolve.h diff --git a/tools/power/x86/turbostat/Makefile b/tools/power/x86/turbostat/Makefile index d1b3a36..745af06 100644 --- a/tools/power/x86/turbostat/Makefile +++ b/tools/power/x86/turbostat/Makefile @@ -3,17 +3,20 @@ BUILD_OUTPUT := $(PWD) PREFIX := /usr DESTDIR:= -turbostat : turbostat.c +turbostat : turbostat.o resolve.o + @mkdir -p $(BUILD_OUTPUT) + $(CC) $(LDFLAGS) $^ -o $(BUILD_OUTPUT)/$@ + CFLAGS += -Wall CFLAGS += -DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"' -%: %.c +%.o: %.c @mkdir -p $(BUILD_OUTPUT) - $(CC) $(CFLAGS) $< -o $(BUILD_OUTPUT)/$@ + $(CC) $(CFLAGS) $< -c -o $(BUILD_OUTPUT)/$@ .PHONY : clean clean : - @rm -f $(BUILD_OUTPUT)/turbostat + @rm -f $(BUILD_OUTPUT)/turbostat turbostat.o resolve.o install : turbostat install -d $(DESTDIR)$(PREFIX)/bin diff --git a/tools/power/x86/turbostat/resolve.c b/tools/power/x86/turbostat/resolve.c new file mode 100644 index 000..ad53159 --- /dev/null +++ b/tools/power/x86/turbostat/resolve.c @@ -0,0 +1,233 @@ +/* Resolve perf style event descriptions to attr */ +/* + * Copyright (c) 2014, Intel Corporation + * Author: Andi Kleen + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + * SERVICES; LOSS OF USE, DATA, OR PROFITS;
