From: "Berthier, Emmanuel" <emmanuel.berthier@intel.com>
To: "'Andy Lutomirski'" <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
"Jarzmik, Robert" <robert.jarzmik@intel.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] [LBR] Dump LBRs on Exception
Date: Thu, 4 Dec 2014 16:01:03 +0000 [thread overview]
Message-ID: <65CD3FC07F3BF942ABE211646D72D770356ED34A@IRSMSX110.ger.corp.intel.com> (raw)
In-Reply-To: <CALCETrVk6XiFeAPKU4bM_ZFFSRmQQvDS=Ascs17qcRM3503ETQ@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3735 bytes --]
> From: Andy Lutomirski [mailto:luto@amacapital.net]
> Sent: Wednesday, December 3, 2014 8:30 PM
> To: Berthier, Emmanuel
> Cc: Thomas Gleixner; H. Peter Anvin; X86 ML; Jarzmik, Robert; LKML
> Subject: Re: [PATCH v2] [LBR] Dump LBRs on Exception
> > The final patch will bypass the new code in case of UserSpace page fault, so
> performance impact will be very low.
> > LBRs copy takes much more time than LBR stop/start.
> >
> > The simple is the better:
> >
> > .macro STOP_LBR
> > #ifdef CONFIG_LBR_DUMP_ON_EXCEPTION
> > testl $3,CS(%rsp) /* Kernel Space? */
> > jnz 1f
> > testl $3, PER_CPU_VAR(lbr_dump_state) /* Disabled? */
> > jnz 1f
>
> But that just wasted two of your LBR slots.
No: false test does not generate Branch record, ex:
Last Branch Records:
to: [<ffffffff828122a0>] page_fault+0x0/0x90
from: [<ffffffff823c0e06>] sysrq_handle_crash+0x16/0x20
to: [<ffffffff823c0df0>] sysrq_handle_crash+0x0/0x20
from: [<ffffffff823c156c>] __handle_sysrq+0x9c/0x170
to: [<ffffffff823c1562>] __handle_sysrq+0x92/0x170
> > push %rax
> > push %rcx
> > push %rdx
> > movl $MSR_IA32_DEBUGCTLMSR, %ecx
> > rdmsr
> > and $~1, %eax /* Disable LBR recording */
> > wrmsr
> > pop %rdx
> > pop %rcx
> > pop %rax
>
> And the general problem with this approach (even ignoring the performance
> hit, and kernel faults on user addresses really do happen in real workloads) is
> that you're not saving and restoring MSR_IA32_DEBUGCTL.
> It may be that
> the rest of your patch does whatever magic is needed to make this work, but
> from just this code it's not at all obvious that this is correct.
The algorithm is quite simple:
When I enter in Exception handler, I stop LBR recording, and dump its content later if needed.
When I leave Exception Handler, I restart LBR recording.
So, after the first exception, LBR in On.
In case of nested Exceptions and crash, you're right, LBR will probably not be relevant.
But your proposal does not solve this issue: If we save registers during 1rst exception, and then overwrite them during 2nd level,
we will lose relevant info if crash is due to the 1rst exception.
> Hence my suggestion for rdmsr -- if you're willing to enable this and take the
> performance hit, you can simplify it a lot and save some branch slots by
> unconditionally doing the rdmsrs if you've enabled the LBR tracing IDT entry.
> The simplification from using rdmsr isn't that the save code is simplified -- it's
> that there's no state change on exception entry, so you don't need to worry
> about restoring state correctly on the way out or during a context switch.
> And you can enable/disable the whole thing just by writing to the IDT, so
> there's no performance hit at all in the disabled case.
Concerning performances: if it's really matter, the better is to disable the CONFIG switch.
But if we enable it, it's for using it I guess, and in that case, bypassing UserSpace page faults is better.
You're proposal of "unconditionally doing the rdmsrs" is not good in that case.
The only small gain is when CONFIG is enable and feature is disabled by cmdline:
- with my proposal, we get 1 test and 1 jmp more (if I switch Kernel test with LBR state test): for an exception treatment, does it really matter?
We can mix our proposals: keep my STOP/START code, and replace the dynamic disabling test by IDT change.
I hope the code will stay readable.
Do we really want to save 2 instructions?
Thanks,
Emmanuel.
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2014-12-04 16:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 17:03 [PATCH] [LBR] Dump LBRs on Oops Emmanuel Berthier
2014-11-22 0:50 ` Thomas Gleixner
2014-11-26 10:56 ` Berthier, Emmanuel
2014-11-26 13:08 ` Thomas Gleixner
2014-11-26 14:17 ` Berthier, Emmanuel
2014-11-26 14:46 ` Thomas Gleixner
2014-11-26 15:43 ` Berthier, Emmanuel
2014-11-27 14:40 ` [PATCH v2] [LBR] Dump LBRs on Exception Emmanuel Berthier
2014-11-27 21:22 ` Thomas Gleixner
2014-11-27 21:56 ` Andy Lutomirski
2014-11-28 8:44 ` Berthier, Emmanuel
2014-11-28 15:15 ` Andy Lutomirski
2014-12-02 19:09 ` Berthier, Emmanuel
2014-12-02 19:33 ` Andy Lutomirski
2014-12-02 19:56 ` Thomas Gleixner
2014-12-02 20:12 ` Andy Lutomirski
2014-12-03 18:25 ` Berthier, Emmanuel
2014-12-03 19:29 ` Andy Lutomirski
2014-12-04 16:01 ` Berthier, Emmanuel [this message]
2014-12-04 18:09 ` Andy Lutomirski
2014-12-05 13:14 ` Berthier, Emmanuel
2014-12-06 10:31 ` Robert Jarzmik
[not found] ` <CALCETrXhfzd9Fkikvm5qj0LWgWtDzgdpY_0EC3ChwyyGZksTMw@mail.gmail.com>
2014-12-07 18:40 ` Robert Jarzmik
2014-12-07 19:10 ` Andy Lutomirski
2014-12-12 17:30 ` Berthier, Emmanuel
2014-12-12 17:54 ` Andy Lutomirski
2014-11-28 10:28 ` Berthier, Emmanuel
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=65CD3FC07F3BF942ABE211646D72D770356ED34A@IRSMSX110.ger.corp.intel.com \
--to=emmanuel.berthier@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=robert.jarzmik@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@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
all inboxes | Powered by JetHome®