From: Tony Lindgren <tony@atomide.com>
To: Lukasz Luba <l.luba@partner.samsung.com>
Cc: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, b.zolnierkie@samsung.com
Subject: Re: [PATCH] config: arm: omap2: remove PROVE_LOCKING from defconfig
Date: Mon, 4 Feb 2019 12:26:04 -0800 [thread overview]
Message-ID: <20190204202604.GP5720@atomide.com> (raw)
In-Reply-To: <21ce2c61-0b20-41f2-4d12-3c5b1c4b7925@partner.samsung.com>
* Lukasz Luba <l.luba@partner.samsung.com> [181113 10:22]:
> Hi Tony,
>
> On 11/8/18 5:59 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Lukasz Luba <l.luba@partner.samsung.com> [181009 08:36]:
> >> PROVE_LOCKING enables LOCKDEP, which causes big overhead on cache and
> >> bus transactions.
> >>
> >> On some ARM big.LITTLE architecutres (Exynos 5433) the overhead is really big.
> >> The overhead can be measures using hackbench which will speed up
> >> by x3 times (11sec -> 3.4sec).
> >> When you check transaction on cache or buses, the results are way higher
> >> than normal for the same hackbench test:
> >> L1d cache invalidations: 26mln vs 4mln
> >> L2u cache invalidations: 42mln vs 12mln
> >> bus cyc/access: 30cyc/access vs. 20cyc/access
> >> context switch is x3 times cheaper
> >>
> >> Enable this option only when you have some locking issue to investigate.
> >
> > I'm all for this, but this disables also other less intrusive
> > debug options. It used to be that we'd get locking issues merged
> > into drivers and I think that's how it originally got enabled.
> That's common reason for a few defconfigs in mainline.
Actually looks like this does not change the DEBUG
related options.. I must have done something wrong
earlier, sorry. So applying into omap-for-v5.1/defconfig.
> > So we should take a look which ones we can or want to keep.
> > Or just disable CONFIG_DEBUG completely.
> Ideally, the CI should try a few 'types' of configs,
> generated based on the 'defconfig'. Some 'smart' script might
> cut the debug options for an image for performance regression tests.
> >
> > For distros, that's multi_v7_defconfig nowadays for most part
> > so I think most people using omap2plus_defconfig are developers
> > working on various devices.
Yes I think that's the case.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-02-04 20:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20181009153624eucas1p2ad30aea33ad1c869f11bd9ca1156d9af@eucas1p2.samsung.com>
2018-10-09 15:36 ` [PATCH] config: arm: omap2: remove PROVE_LOCKING from defconfig Lukasz Luba
2018-11-08 16:59 ` Tony Lindgren
2018-11-13 10:22 ` Lukasz Luba
2019-02-04 20:26 ` Tony Lindgren [this message]
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=20190204202604.GP5720@atomide.com \
--to=tony@atomide.com \
--cc=b.zolnierkie@samsung.com \
--cc=l.luba@partner.samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).