From: "Jörg Krause" <joerg.krause@embedded.rocks>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] ubifs: Fix regression in ubifs_readdir()
Date: Thu, 03 Nov 2016 08:23:34 +0100 [thread overview]
Message-ID: <1478157814.9853.1.camel@embedded.rocks> (raw)
In-Reply-To: <87f68565-765b-4e9b-a3f0-34dae0b45e93@mind.be>
On Thu, 2016-11-03 at 03:46 +0100, Arnout Vandecappelle wrote:
>
> On 02-11-16 23:49, J?rg Krause wrote:
> > On Wed, 2016-11-02 at 21:49 +0100, Thomas Petazzoni wrote:
> > > Hello,
> > >
> > > On Wed, 02 Nov 2016 20:56:59 +0100, J?rg Krause wrote:
> > >
> > > > > This is *really* bad. Which Buildroot version are you
> > > > > using???
> > > >
> > > > 2016.11 #
> > > >
> > > > Note that I am using Buildroot as a submodule [1] and I needed
> > > > to
> > > > port
> > > > the br2-external tree. Maybe I messed something up?
> > > >
> > > > > Are you able to reproduce the bad ccache behavior here???
> > > >
> > > > Yes, I am. Linux kernel source directory is located locally and
> > > > the
> > > > path is set using LINUX_OVERRIDE_SRCDIR in local.mk.
> > > >
> > > > 1/ Checkout Linux kernel version 4.7.10
> > > > 2/ make linux-dirclean all
> > > > 3/ Booted Linux version is 4.7.10
> > > >
> > > > 4/ Checkout Linux kernel version 4.8.5
> > > > 5/ make linux-dirclean all
> > > > 6/ Booted Linux version is still 4.7.10
> > >
> > > And this scenario works fine with ccache *disabled*, but breaks
> > > when
> > > you enable ccache support in Buildroot?
> >
> > Yes.
>
> ?I can't reproduce this. I've got a nice mix of cache misses and
> cache hits when
> building a different version, and version.o is definitely a cache
> miss.
>
> ?Can you double-check the version in output/build/linux-
> custom/init/version.o?
I checked the version string in version.o with hexdump -C and they
differ.
> And the one in output/build/linux-
> custom/include/generated/utsrelease.h?
This as well.
> ?Hm, hang on, is there maybe a utsrelease.h that ends up in your
> staging dir and that is used by ccache?
No, there is only the linux generated file.
---
I am not experienced with ccache, but I got some statistics:
I cleared the cache by removing ~/.buildroot-ccache, than run `make
linux-dirclean linux`:
cache hit (direct)?????????????????????0
cache hit (preprocessed)???????????????0
cache miss??????????????????????????1088
cache hit rate??????????????????????0.00 %
called for link???????????????????????10
called for preprocessing???????????????5
no input file????????????????????????394
cleanups performed?????????????????????0
files in cache??????????????????????3250
Then I re-run `make linux-dirclean linux` (without altering the linux
sources):
cache hit (direct)??????????????????1076
cache hit (preprocessed)??????????????10
cache miss??????????????????????????1090
cache hit rate?????????????????????49.91 %
called for link???????????????????????20
called for preprocessing??????????????10
no input file????????????????????????788
cleanups performed?????????????????????0
files in cache??????????????????????3264
Again, clear the cache and run `make linux-dirclean linux`, but alter
the linux sources by checking out a different branch:
cache hit (direct)????????????????????10
cache hit (preprocessed)??????????????62
cache miss??????????????????????????2102
cache hit rate??????????????????????3.31 %
called for link???????????????????????20
called for preprocessing??????????????10
no input file????????????????????????773
cleanups performed?????????????????????0
files in cache??????????????????????6386
---
Furthermore, I did the following for the different linux builds:
After building branch-4.7.y:
# cp output/build/linux-custom/arch/arm/boot/zImage zImage-4.7.10
After building branch-4.8.y:
# cp output/build/linux-custom/arch/arm/boot/zImage zImage-4.8.5
Afterwards, diff shows no differences:
# diff zImage-4.7.10 zImage-4.8.5
Best regards,
J?rg Krause
next prev parent reply other threads:[~2016-11-03 7:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1477648432-9543-1-git-send-email-richard@nod.at>
[not found] ` <1477671544.8927.1.camel@embedded.rocks>
[not found] ` <c542e099-0404-be8e-ebeb-d4265d3204d6@nod.at>
[not found] ` <1477693395.31471.1.camel@embedded.rocks>
2016-11-01 22:22 ` [Buildroot] [PATCH] ubifs: Fix regression in ubifs_readdir() Thomas Petazzoni
2016-11-02 19:56 ` Jörg Krause
2016-11-02 20:49 ` Thomas Petazzoni
2016-11-02 22:49 ` Jörg Krause
2016-11-03 2:46 ` Arnout Vandecappelle
2016-11-03 7:23 ` Jörg Krause [this message]
2016-11-03 10:22 ` Arnout Vandecappelle
2016-11-07 22:08 ` Jörg Krause
2016-11-07 22:24 ` Jörg Krause
2016-11-07 22:54 ` Jörg Krause
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1478157814.9853.1.camel@embedded.rocks \
--to=joerg.krause@embedded.rocks \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox