From: Peter Zijlstra <peterz@infradead.org> Date: 2021-06-14 10:57:02
On Mon, Jun 14, 2021 at 02:39:41AM -0700, Bill Wendling wrote:
On Mon, Jun 14, 2021 at 2:01 AM Peter Zijlstra [off-list ref] wrote:
quoted
Because having GCOV, KCOV and PGO all do essentially the same thing
differently, makes heaps of sense?
It does when you're dealing with one toolchain without access to another.
Here's a sekrit, don't tell anyone, but you can get a free copy of GCC
right here:
https://gcc.gnu.org/
We also have this linux-toolchains list (Cc'ed now) that contains folks
from both sides.
quoted
I understand that the compilers actually generates radically different
instrumentation for the various cases, but essentially they're all
collecting (function/branch) arcs.
That's true, but there's no one format for profiling data that's
usable between all compilers. I'm not even sure there's a good way to
translate between, say, gcov and llvm's format. To make matters more
complicated, each compiler's format is tightly coupled to a specific
version of that compiler. And depending on *how* the data is collected
(e.g. sampling or instrumentation), it may not give us the full
benefit of FDO/PGO.
I'm thinking that something simple like:
struct arc {
u64 from;
u64 to;
u64 nr;
u64 cntrs[0];
};
goes a very long way. Stick a header on that says how large cntrs[] is,
and some other data (like load offset and whatnot) and you should be
good.
Combine that with the executable image (say /proc/kcore) to recover
what's @from (call, jmp or conditional branch) and I'm thinking one
ought to be able to construct lots of useful data.
I've also been led to believe that the KCOV data format is not in fact
dependent on which toolchain is used.
quoted
I'm thinking it might be about time to build _one_ infrastructure for
that and define a kernel arc format and call it a day.
That may be nice, but it's a rather large request.
Given GCOV just died, perhaps you can look at what KCOV does and see if
that can be extended to do as you want. KCOV is actively used and
we actually tripped over all the fun little noinstr bugs at the time.
From: Bill Wendling <morbo@google.com> Date: 2021-06-14 11:45:05
On Mon, Jun 14, 2021 at 3:45 AM Peter Zijlstra [off-list ref] wrote:
On Mon, Jun 14, 2021 at 02:39:41AM -0700, Bill Wendling wrote:
quoted
On Mon, Jun 14, 2021 at 2:01 AM Peter Zijlstra [off-list ref] wrote:
quoted
quoted
Because having GCOV, KCOV and PGO all do essentially the same thing
differently, makes heaps of sense?
It does when you're dealing with one toolchain without access to another.
Here's a sekrit, don't tell anyone, but you can get a free copy of GCC
right here:
https://gcc.gnu.org/
We also have this linux-toolchains list (Cc'ed now) that contains folks
from both sides.
Your sarcasm is not useful.
quoted
quoted
I understand that the compilers actually generates radically different
instrumentation for the various cases, but essentially they're all
collecting (function/branch) arcs.
That's true, but there's no one format for profiling data that's
usable between all compilers. I'm not even sure there's a good way to
translate between, say, gcov and llvm's format. To make matters more
complicated, each compiler's format is tightly coupled to a specific
version of that compiler. And depending on *how* the data is collected
(e.g. sampling or instrumentation), it may not give us the full
benefit of FDO/PGO.
I'm thinking that something simple like:
struct arc {
u64 from;
u64 to;
u64 nr;
u64 cntrs[0];
};
goes a very long way. Stick a header on that says how large cntrs[] is,
and some other data (like load offset and whatnot) and you should be
good.
Combine that with the executable image (say /proc/kcore) to recover
what's @from (call, jmp or conditional branch) and I'm thinking one
ought to be able to construct lots of useful data.
I've also been led to believe that the KCOV data format is not in fact
dependent on which toolchain is used.
quoted
quoted
I'm thinking it might be about time to build _one_ infrastructure for
that and define a kernel arc format and call it a day.
That may be nice, but it's a rather large request.
Given GCOV just died, perhaps you can look at what KCOV does and see if
that can be extended to do as you want. KCOV is actively used and
we actually tripped over all the fun little noinstr bugs at the time.
From: Bill Wendling <morbo@google.com> Date: 2021-06-14 11:45:45
On Mon, Jun 14, 2021 at 3:45 AM Peter Zijlstra [off-list ref] wrote:
On Mon, Jun 14, 2021 at 02:39:41AM -0700, Bill Wendling wrote:
quoted
On Mon, Jun 14, 2021 at 2:01 AM Peter Zijlstra [off-list ref] wrote:
quoted
I understand that the compilers actually generates radically different
instrumentation for the various cases, but essentially they're all
collecting (function/branch) arcs.
That's true, but there's no one format for profiling data that's
usable between all compilers. I'm not even sure there's a good way to
translate between, say, gcov and llvm's format. To make matters more
complicated, each compiler's format is tightly coupled to a specific
version of that compiler. And depending on *how* the data is collected
(e.g. sampling or instrumentation), it may not give us the full
benefit of FDO/PGO.
I'm thinking that something simple like:
struct arc {
u64 from;
u64 to;
u64 nr;
u64 cntrs[0];
};
goes a very long way. Stick a header on that says how large cntrs[] is,
and some other data (like load offset and whatnot) and you should be
good.
Combine that with the executable image (say /proc/kcore) to recover
what's @from (call, jmp or conditional branch) and I'm thinking one
ought to be able to construct lots of useful data.
I've also been led to believe that the KCOV data format is not in fact
dependent on which toolchain is used.
Awesome! I await your RFC on both the gcc and clang mailing lists.
-bw
quoted
quoted
I'm thinking it might be about time to build _one_ infrastructure for
that and define a kernel arc format and call it a day.
That may be nice, but it's a rather large request.
Given GCOV just died, perhaps you can look at what KCOV does and see if
that can be extended to do as you want. KCOV is actively used and
we actually tripped over all the fun little noinstr bugs at the time.
From: Marco Elver <elver@google.com> Date: 2021-06-14 14:17:42
On Mon, 14 Jun 2021 at 12:45, Peter Zijlstra [off-list ref] wrote:
[...]
I've also been led to believe that the KCOV data format is not in fact
dependent on which toolchain is used.
Correct, we use KCOV with both gcc and clang. Both gcc and clang emit
the same instrumentation for -fsanitize-coverage. Thus, the user-space
portion and interface is indeed identical:
https://www.kernel.org/doc/html/latest/dev-tools/kcov.html
quoted
quoted
I'm thinking it might be about time to build _one_ infrastructure for
that and define a kernel arc format and call it a day.
That may be nice, but it's a rather large request.
Given GCOV just died, perhaps you can look at what KCOV does and see if
that can be extended to do as you want. KCOV is actively used and
we actually tripped over all the fun little noinstr bugs at the time.
There might be a subtle mismatch between coverage instrumentation for
testing/fuzzing and for profiling. (Disclaimer: I'm not too familiar
with Clang-PGO's requirements.) For example, while for testing/fuzzing
we may only require information if a code-path has been visited, for
profiling the "hotness" might be of interest. Therefore, the
user-space exported data format can make several trade-offs in
complexity.
In theory, I imagine there's a limit to how generic one could make
profiling information, because one compiler's optimizations are not
another compiler's optimizations. On the other hand, it may be doable
to collect unified profiling information for common stuff, but I guess
there's little motivation for figuring out the common ground given the
producer and consumer of the PGO data is the same compiler by design
(unlike coverage info for testing/fuzzing).
Therefore, if KCOV's exposed information does not match PGO's
requirements today, I'm not sure what realistically can be done
without turning KCOV into a monster. Because KCOV is optimized for
testing/fuzzing coverage, and I'm not sure how complex we can or want
to make it to cater to a new use-case.
My intuition is that the simpler design is to have 2 subsystems for
instrumentation-based coverage collection: one for testing/fuzzing,
and the other for profiling.
Alas, there's the problem of GCOV, which should be replaceable by KCOV
for most use cases. But it would be good to hear from a GCOV user if
there are some.
But as we learned GCOV is broken on x86 now, I see these options:
1. Remove GCOV, make KCOV the de-facto test-coverage collection
subsystem. Introduce PGO-instrumentation subsystem for profile
collection only, and make it _very_ clear that KCOV != PGO data as
hinted above. A pre-requisite is that compiler-support for PGO
instrumentation adds selective instrumentation support, likely just
making attribute no_instrument_function do the right thing.
2. Like (1) but also keep GCOV, given proper support for attribute
no_instrument_function would probably fix it (?).
3. Keep GCOV (and KCOV of course). Somehow extract PGO profiles from KCOV.
4. Somehow extract PGO profiles from GCOV, or modify kernel/gcov to do so.
Thanks.
On Mon, Jun 14, 2021 at 04:16:16PM +0200, 'Marco Elver' via Clang Built Linux wrote:
On Mon, 14 Jun 2021 at 12:45, Peter Zijlstra [off-list ref] wrote:
[...]
quoted
I've also been led to believe that the KCOV data format is not in fact
dependent on which toolchain is used.
Correct, we use KCOV with both gcc and clang. Both gcc and clang emit
the same instrumentation for -fsanitize-coverage. Thus, the user-space
portion and interface is indeed identical:
https://www.kernel.org/doc/html/latest/dev-tools/kcov.html
quoted
quoted
quoted
I'm thinking it might be about time to build _one_ infrastructure for
that and define a kernel arc format and call it a day.
That may be nice, but it's a rather large request.
Given GCOV just died, perhaps you can look at what KCOV does and see if
that can be extended to do as you want. KCOV is actively used and
we actually tripped over all the fun little noinstr bugs at the time.
There might be a subtle mismatch between coverage instrumentation for
testing/fuzzing and for profiling. (Disclaimer: I'm not too familiar
with Clang-PGO's requirements.) For example, while for testing/fuzzing
we may only require information if a code-path has been visited, for
profiling the "hotness" might be of interest. Therefore, the
user-space exported data format can make several trade-offs in
complexity.
This has been my primary take-away: given that Clang's PGO is different
enough from the other things and provides more specific/actionable
results, I think it's justified to exist on its own separate from the
other parts.
In theory, I imagine there's a limit to how generic one could make
profiling information, because one compiler's optimizations are not
another compiler's optimizations. On the other hand, it may be doable
to collect unified profiling information for common stuff, but I guess
there's little motivation for figuring out the common ground given the
producer and consumer of the PGO data is the same compiler by design
(unlike coverage info for testing/fuzzing).
Therefore, if KCOV's exposed information does not match PGO's
requirements today, I'm not sure what realistically can be done
without turning KCOV into a monster. Because KCOV is optimized for
testing/fuzzing coverage, and I'm not sure how complex we can or want
to make it to cater to a new use-case.
My intuition is that the simpler design is to have 2 subsystems for
instrumentation-based coverage collection: one for testing/fuzzing,
and the other for profiling.
Alas, there's the problem of GCOV, which should be replaceable by KCOV
for most use cases. But it would be good to hear from a GCOV user if
there are some.
But as we learned GCOV is broken on x86 now, I see these options:
1. Remove GCOV, make KCOV the de-facto test-coverage collection
subsystem. Introduce PGO-instrumentation subsystem for profile
collection only, and make it _very_ clear that KCOV != PGO data as
hinted above. A pre-requisite is that compiler-support for PGO
instrumentation adds selective instrumentation support, likely just
making attribute no_instrument_function do the right thing.
Right. I can't speak to GCOV, but KCOV certainly isn't PGO.
2. Like (1) but also keep GCOV, given proper support for attribute
no_instrument_function would probably fix it (?).
3. Keep GCOV (and KCOV of course). Somehow extract PGO profiles from KCOV.
4. Somehow extract PGO profiles from GCOV, or modify kernel/gcov to do so.
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-06-14 15:36:26
On Mon, Jun 14, 2021 at 08:26:01AM -0700, Kees Cook wrote:
So, AFAICT, the original blocking issue ("PGO does not respect noinstr")
is not actually an issue (noinstr contains notrace, which IS respected
by PGO[2]), I think this is fine to move forward.
It is *NOT*: https://godbolt.org/z/9c7xdvGd9
Look at how both compilers generate instrumentation in the no_instr()
function.
From: Peter Zijlstra <peterz@infradead.org> Date: 2021-06-14 15:46:58
On Mon, Jun 14, 2021 at 08:26:01AM -0700, Kees Cook wrote:
quoted
2. Like (1) but also keep GCOV, given proper support for attribute
no_instrument_function would probably fix it (?).
3. Keep GCOV (and KCOV of course). Somehow extract PGO profiles from KCOV.
4. Somehow extract PGO profiles from GCOV, or modify kernel/gcov to do so.
If there *is* a way to "combine" these, I don't think it makes sense
to do it now. PGO has users (and is expanding[1]), and trying to
optimize the design before even landing the first version seems like a
needless obstruction, and to likely not address currently undiscovered
requirements.
Even if that were so (and I'm not yet convinced), the current proposal
is wedded to llvm-pgo, there is no way gcc-pgo could reuse any of this
code afaict, which then means they have to create yet another variant.
Sorting this *before* the first version is exactly the right time.
Since when are we merging code when the requirements are not clear?
Just to clarify:
Nacked-by: Peter Zijlstra (Intel) [off-list ref]
For all this PGO crud.
From: Nick Desaulniers <ndesaulniers@google.com> Date: 2021-06-14 16:03:34
On Mon, Jun 14, 2021 at 8:46 AM Peter Zijlstra [off-list ref] wrote:
On Mon, Jun 14, 2021 at 08:26:01AM -0700, Kees Cook wrote:
quoted
quoted
2. Like (1) but also keep GCOV, given proper support for attribute
no_instrument_function would probably fix it (?).
3. Keep GCOV (and KCOV of course). Somehow extract PGO profiles from KCOV.
4. Somehow extract PGO profiles from GCOV, or modify kernel/gcov to do so.
If there *is* a way to "combine" these, I don't think it makes sense
to do it now. PGO has users (and is expanding[1]), and trying to
optimize the design before even landing the first version seems like a
needless obstruction, and to likely not address currently undiscovered
requirements.
Even if that were so (and I'm not yet convinced), the current proposal
is wedded to llvm-pgo, there is no way gcc-pgo could reuse any of this
code afaict, which then means they have to create yet another variant.
Similar to GCOV, the runtime support for exporting such data is
heavily compiler (and compiler version) specific, as is the data
format for compilers to consume. We were able to reuse most of the
runtime code between GCC and Clang support in GCOV; I don't see why we
couldn't do a similar factoring of the runtime code being added to the
kernel here, should anyone care to pursue implementing PGO with GCC.
Having an implementation is a great starting point for folks looking
to extend support or to understand how to support PGO in such a bare
metal environment (one that doesn't dynamically link against
traditional compiler runtimes).
--
Thanks,
~Nick Desaulniers
On Mon, Jun 14, 2021 at 05:35:45PM +0200, Peter Zijlstra wrote:
On Mon, Jun 14, 2021 at 08:26:01AM -0700, Kees Cook wrote:
quoted
So, AFAICT, the original blocking issue ("PGO does not respect noinstr")
is not actually an issue (noinstr contains notrace, which IS respected
by PGO[2]), I think this is fine to move forward.
It is *NOT*: https://godbolt.org/z/9c7xdvGd9
Look at how both compilers generate instrumentation in the no_instr()
function.
Well that's disappointing. I'll put this on hold until Clang can grow an
appropriate attribute (or similar work-around). Thanks for catching
that.
--
Kees Cook
From: Nick Desaulniers <ndesaulniers@google.com> Date: 2021-06-14 18:09:28
On Mon, Jun 14, 2021 at 9:23 AM Kees Cook [off-list ref] wrote:
On Mon, Jun 14, 2021 at 05:35:45PM +0200, Peter Zijlstra wrote:
quoted
On Mon, Jun 14, 2021 at 08:26:01AM -0700, Kees Cook wrote:
quoted
So, AFAICT, the original blocking issue ("PGO does not respect noinstr")
is not actually an issue (noinstr contains notrace, which IS respected
by PGO[2]), I think this is fine to move forward.
It is *NOT*: https://godbolt.org/z/9c7xdvGd9
Look at how both compilers generate instrumentation in the no_instr()
function.
Well that's disappointing. I'll put this on hold until Clang can grow an
appropriate attribute (or similar work-around). Thanks for catching
that.
From: Nick Desaulniers <ndesaulniers@google.com> Date: 2021-06-14 20:50:45
On Mon, Jun 14, 2021 at 11:07 AM Nick Desaulniers
[off-list ref] wrote:
On Mon, Jun 14, 2021 at 9:23 AM Kees Cook [off-list ref] wrote:
quoted
On Mon, Jun 14, 2021 at 05:35:45PM +0200, Peter Zijlstra wrote:
quoted
On Mon, Jun 14, 2021 at 08:26:01AM -0700, Kees Cook wrote:
quoted
So, AFAICT, the original blocking issue ("PGO does not respect noinstr")
is not actually an issue (noinstr contains notrace, which IS respected
by PGO[2]), I think this is fine to move forward.
It is *NOT*: https://godbolt.org/z/9c7xdvGd9
Look at how both compilers generate instrumentation in the no_instr()
function.
Well that's disappointing. I'll put this on hold until Clang can grow an
appropriate attribute (or similar work-around). Thanks for catching
that.