oprofile rebuilds for different MACHINES (sstate)

oprofile rebuilds for different MACHINES (sstate)

[Denys Dmytriyenko]

So, I've been debugging the issue of oprofile rebuilding from one MACHINE to 
another (causing PR issues, etc). I was able to trace it down to this line:

EXTRA_OECONF = "--with-kernel=${STAGING_KERNEL_DIR}  --without-x ac_cv_prog_XSLTPROC="

And STAGING_KERNEL_DIR resolves to this:

STAGING_KERNEL_DIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-source"

Now, obviously, when MACHINE changes, sstate invalidates do_configure and 
rebuilds oprofile.

The question is, what is the proper fix in this case - mark oprofile as 
machine-specific with PACKAGE_ARCH = "${MACHINE_ARCH}", since it will be 
configuring and building against (potentially) completely different kernel 
tree. So, just mark it explicitly and be safe...

Or another option is to tell sstate to ignore changes to the above variables 
with this simple line:

EXTRA_OECONF[vardepsexclude] = "STAGING_KERNEL_DIR"

This also does the trick, but I'm a bit worried there could be side-effects of 
using oprofile against the wrong kernel... Any recommendations?

-- 
Denys

Re: oprofile rebuilds for different MACHINES (sstate)

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]


> On Aug 11, 2015, at 8:26 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> 
> So, I've been debugging the issue of oprofile rebuilding from one MACHINE to
> another (causing PR issues, etc). I was able to trace it down to this line:
> 
> EXTRA_OECONF = "--with-kernel=${STAGING_KERNEL_DIR}  --without-x ac_cv_prog_XSLTPROC="
> 
> And STAGING_KERNEL_DIR resolves to this:
> 
> STAGING_KERNEL_DIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-source"
> 
> Now, obviously, when MACHINE changes, sstate invalidates do_configure and
> rebuilds oprofile.
> 
> The question is, what is the proper fix in this case - mark oprofile as
> machine-specific with PACKAGE_ARCH = "${MACHINE_ARCH}", since it will be
> configuring and building against (potentially) completely different kernel
> tree. So, just mark it explicitly and be safe...
> 
> Or another option is to tell sstate to ignore changes to the above variables
> with this simple line:
> 
> EXTRA_OECONF[vardepsexclude] = "STAGING_KERNEL_DIR"
> 
> This also does the trick, but I'm a bit worried there could be side-effects of
> using oprofile against the wrong kernel... Any recommendations?

Using kernel staging dir is unnecessary here, oprofile’s configure is poking for user space APIs
in linux/perf_event.h so linux-libc-headers dependency is enough. and use —with-kernel=${STAGING_EXECPREFIXDIR}
instead of STAGING_KERNEL_DIR, that should fix it.

-Khem

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: oprofile rebuilds for different MACHINES (sstate)

[Philip Balister]

On 08/12/2015 05:26 AM, Denys Dmytriyenko wrote:
> So, I've been debugging the issue of oprofile rebuilding from one MACHINE to 
> another (causing PR issues, etc). I was able to trace it down to this line:

Why not use perf instead of oprofile?

Philip

> 
> EXTRA_OECONF = "--with-kernel=${STAGING_KERNEL_DIR}  --without-x ac_cv_prog_XSLTPROC="
> 
> And STAGING_KERNEL_DIR resolves to this:
> 
> STAGING_KERNEL_DIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-source"
> 
> Now, obviously, when MACHINE changes, sstate invalidates do_configure and 
> rebuilds oprofile.
> 
> The question is, what is the proper fix in this case - mark oprofile as 
> machine-specific with PACKAGE_ARCH = "${MACHINE_ARCH}", since it will be 
> configuring and building against (potentially) completely different kernel 
> tree. So, just mark it explicitly and be safe...
> 
> Or another option is to tell sstate to ignore changes to the above variables 
> with this simple line:
> 
> EXTRA_OECONF[vardepsexclude] = "STAGING_KERNEL_DIR"
> 
> This also does the trick, but I'm a bit worried there could be side-effects of 
> using oprofile against the wrong kernel... Any recommendations?
> 

Re: oprofile rebuilds for different MACHINES (sstate)

[Denys Dmytriyenko]

On Tue, Aug 11, 2015 at 09:35:42PM -0700, Khem Raj wrote:
> 
> > On Aug 11, 2015, at 8:26 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> > 
> > So, I've been debugging the issue of oprofile rebuilding from one MACHINE to
> > another (causing PR issues, etc). I was able to trace it down to this line:
> > 
> > EXTRA_OECONF = "--with-kernel=${STAGING_KERNEL_DIR}  --without-x ac_cv_prog_XSLTPROC="
> > 
> > And STAGING_KERNEL_DIR resolves to this:
> > 
> > STAGING_KERNEL_DIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-source"
> > 
> > Now, obviously, when MACHINE changes, sstate invalidates do_configure and
> > rebuilds oprofile.
> > 
> > The question is, what is the proper fix in this case - mark oprofile as
> > machine-specific with PACKAGE_ARCH = "${MACHINE_ARCH}", since it will be
> > configuring and building against (potentially) completely different kernel
> > tree. So, just mark it explicitly and be safe...
> > 
> > Or another option is to tell sstate to ignore changes to the above variables
> > with this simple line:
> > 
> > EXTRA_OECONF[vardepsexclude] = "STAGING_KERNEL_DIR"
> > 
> > This also does the trick, but I'm a bit worried there could be side-effects of
> > using oprofile against the wrong kernel... Any recommendations?
> 
> Using kernel staging dir is unnecessary here, oprofile’s configure is poking for user space APIs
> in linux/perf_event.h so linux-libc-headers dependency is enough. and use —with-kernel=${STAGING_EXECPREFIXDIR}
> instead of STAGING_KERNEL_DIR, that should fix it.

Thanks. It didn't seem to help with oprofile, as it changes hashes anyway due 
to the kernel:do_populate_sysroot...

But it did help with cryptodev-tests re-packaging - patch is on the list.

-- 
Denys