Added a few more things. We don't have a kernel version, do we? Kernel: /usr/local/google/home/src/akaros/akaros/obj/kern/akaros-kernel Date: Sun Dec 13 11:03:28 PST 2015 Host: dlibenzi.mtv.corp.google.com
On Sun, Dec 13, 2015 at 11:00 AM, Davide Libenzi <[email protected]> wrote: > To get me unlocked, I added this rule to the makefile, on which fill-kfs > depends. > If we want to change it later on, thats fine. > > create-build-file: > ifneq ($(INVARIANT_BUILD),1) > @echo "Kernel: $(abspath $(KERNEL_OBJ))" > kern/kfs/etc/build.info > endif > > > > On Sun, Dec 13, 2015 at 10:39 AM, Davide Libenzi <[email protected]> > wrote: > >> Also, KFS uses CPIO, which in turn embeds file metadata (time as well). >> So our builds will have to either point to an invariant KFS, or not have >> it at all. >> >> >> On Sun, Dec 13, 2015 at 10:37 AM, Davide Libenzi <[email protected]> >> wrote: >> >>> If this will ever be an issue, we can have a build option which does not >>> include neither KFS (because the same invariant will have to apply to its >>> populated ELF files as well), nor other build dependent information. >>> Without that, you will not be able to use perf to generate traces though. >>> >>> >>> On Sun, Dec 13, 2015 at 10:31 AM, ron minnich <[email protected]> >>> wrote: >>> >>>> It's true that that non-reproducible bits are typically embedded in a >>>> linux kernel at present. That may change. >>>> >>>> But debian and coreboot at least are looking at the problem. >>>> >>>> We can try to get it right from the start. >>>> >>>> ron >>>> >>>> On Sun, Dec 13, 2015 at 9:58 AM 'Davide Libenzi' via Akaros < >>>> [email protected]> wrote: >>>> >>>>> Now our KFS image is stuck in an ELF section as well. >>>>> The typical kernel uname info is generally generated (at least the >>>>> time part) and compile time as well. >>>>> >>>>> >>>>> On Sun, Dec 13, 2015 at 9:52 AM, ron minnich <[email protected]> >>>>> wrote: >>>>> >>>>>> Sorry, what I mean is we have to be careful what we put into the >>>>>> kernel image, so that different people can build kernels >>>>>> that are byte for byte the same given a git ref. This reproducible >>>>>> build stuff is all the rage now. >>>>>> >>>>>> I think putting stuff like paths in the kernel binary will defeat >>>>>> reproducible builds. >>>>>> >>>>>> ron >>>>>> >>>>>> On Sun, Dec 13, 2015 at 9:50 AM 'Davide Libenzi' via Akaros < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Did not parse that ☺ >>>>>>> >>>>>>> >>>>>>> On Sun, Dec 13, 2015 at 9:48 AM, ron minnich <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> One thing is it would be nice if however we do this, we can make >>>>>>>> sure we have reproducible builds, which the >>>>>>>> ELF approach might cause trouble with. >>>>>>>> >>>>>>>> ron >>>>>>>> >>>>>>>> On Sun, Dec 13, 2015 at 9:43 AM 'Davide Libenzi' via Akaros < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> There is a way, and Linux perf has an ID for every trace, ID which >>>>>>>>> you can bind to any event string you can push into the perf file. >>>>>>>>> But, in order to do that, I will need to add libpfm4 dependency to >>>>>>>>> kprof2perf, which is not worth it. >>>>>>>>> Instead I will go ahead to move the akaros to linux perf >>>>>>>>> conversion, to the akaros perf tool (which already has the libpfm4 >>>>>>>>> dependency), and drop the kprof2perf tool altogether. >>>>>>>>> In order to do that though, I will need to know, on the Akaros >>>>>>>>> side, the full path within the build directory, of the akaros kernel >>>>>>>>> ELF >>>>>>>>> file. >>>>>>>>> A couple of solutions which come to my mind: >>>>>>>>> >>>>>>>>> 1) Build system create a magic build info file into KFS >>>>>>>>> 2) Build info are stuck in a kernel ELF section, retrievable via >>>>>>>>> system call or #some-dev-file >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Dec 12, 2015 at 4:53 PM, Davide Libenzi < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> On Fri, Dec 11, 2015 at 12:09 PM, Davide Libenzi < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> > +void perfmon_interrupt(struct hw_trapframe *hw_tf, void *data) >>>>>>>>>>>> > +{ >>>>>>>>>>>> > + int i; >>>>>>>>>>>> > + struct perfmon_cpu_context *cctx = >>>>>>>>>>>> PERCPU_VARPTR(counters_env); >>>>>>>>>>>> > + uint64_t gctrl, status; >>>>>>>>>>>> > + >>>>>>>>>>>> > + profiler_add_hw_sample(hw_tf); >>>>>>>>>>>> >>>>>>>>>>>> So it looks like we generate a trace whenever any of the >>>>>>>>>>>> counters overflow, but >>>>>>>>>>>> we lose track of which one overflowed. I guess that's what >>>>>>>>>>>> userland perf >>>>>>>>>>>> expects? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I need to add an "ID", and figure out how to pass that to >>>>>>>>>>> userland perf. >>>>>>>>>>> Will do in follow up CL. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Actually, doing it in this stream, as tail commits. >>>>>>>>>> I already added an "info" field containing the event coordinates. >>>>>>>>>> Need to figure out how to translate it for Linux perf now ... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "Akaros" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Akaros" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To post to this group, send email to [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Akaros" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Akaros" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Akaros" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Akaros" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
