ld thus be
considered for backport.
v2:
- Print the warning when the event happens so the reg,val make sense
- But print it only for the first such instance
- Update changelog to include details of failing system
Signed-off-by: George Dunlap
CC: Konrad Wilk
CC: Thomas Gleixner
CC: "H. P
Any opinions on this? It's been 2 weeks now.
-George
On 18/03/13 11:27, George Dunlap wrote:
check_hw_exists has a number of checks which go to two exit paths:
msr_fail and bios_fail. Checks classified as msr_fail will cause
check_hw_exists() to return false, causing the PMU not to be
ned-off-by: George Dunlap
CC: Konrad Wilk
CC: Thomas Gleixner
CC: "H. Peter Anvin"
CC: Ingo Molnar
CC: x...@kernel.org
CC: Ian Campbell
CC: David Vrabel
CC: Andrew Cooper
---
arch/x86/kernel/cpu/perf_event.c | 30 ++
1 file changed, 18 insertions(+), 1
Any comments? it's been 2 weeks now.
Thanks,
-George
On 03/04/13 15:46, George Dunlap wrote:
check_hw_exists has a number of checks which go to two exit paths:
msr_fail and bios_fail. Checks classified as msr_fail will cause
check_hw_exists() to return false, causing the PMU not to be
On 12/06/13 14:45, Konrad Rzeszutek Wilk wrote:
On Tue, Jun 11, 2013 at 05:17:45PM +0100, George Dunlap wrote:
On 06/11/2013 05:08 PM, konrad wilk wrote:
On 6/11/2013 11:36 AM, George Dunlap wrote:
On 06/10/2013 10:06 PM, Konrad Rzeszutek Wilk wrote:
There are two tool-stack that can
On 06/11/2013 08:29 AM, Jan Beulich wrote:
On 10.06.13 at 23:06, Konrad Rzeszutek Wilk wrote:
There are two tool-stack that can instruct the Xen PCI frontend
and backend to change states: 'xm' (Python code with a daemon),
and 'xl' (C library - does not keep state changes).
With the 'xm', the p
On 06/10/2013 10:06 PM, Konrad Rzeszutek Wilk wrote:
There are two tool-stack that can instruct the Xen PCI frontend
and backend to change states: 'xm' (Python code with a daemon),
and 'xl' (C library - does not keep state changes).
With the 'xm', the path to disconnect a PCI device (xm pci-deta
On 06/11/2013 05:08 PM, konrad wilk wrote:
On 6/11/2013 11:36 AM, George Dunlap wrote:
On 06/10/2013 10:06 PM, Konrad Rzeszutek Wilk wrote:
There are two tool-stack that can instruct the Xen PCI frontend
and backend to change states: 'xm' (Python code with a daemon),
and '
On 18/03/13 11:27, George Dunlap wrote:
check_hw_exists has a number of checks which go to two exit paths:
msr_fail and bios_fail. Checks classified as msr_fail will cause
check_hw_exists() to return false, causing the PMU not to be used;
bios_fail checks will only cause a warning to be printed
Any thoughts on this?
Thanks,
-George
On 03/04/13 15:46, George Dunlap wrote:
check_hw_exists has a number of checks which go to two exit paths:
msr_fail and bios_fail. Checks classified as msr_fail will cause
check_hw_exists() to return false, causing the PMU not to be used;
bios_fail
On Mon, Apr 13, 2015 at 2:49 PM, Eric Dumazet wrote:
> On Mon, 2015-04-13 at 11:56 +0100, George Dunlap wrote:
>
>> Is the problem perhaps that netback/netfront delays TX completion?
>> Would it be better to see if that can be addressed properly, so that
>> the origi
On 04/15/2015 05:38 PM, Eric Dumazet wrote:
> My thoughts that instead of these long talks you should guys read the
> code :
>
> /* TCP Small Queues :
> * Control number of packets in qdisc/devices to two packets
> / or ~1 ms.
> * This allows for
On 04/15/2015 06:29 PM, Eric Dumazet wrote:
> On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
>> On 04/15/2015 05:38 PM, Eric Dumazet wrote:
>>> My thoughts that instead of these long talks you should guys read the
>>> code :
>>>
>
On 04/15/2015 06:52 PM, Eric Dumazet wrote:
> On Wed, 2015-04-15 at 18:41 +0100, George Dunlap wrote:
>
>> So you'd be OK with a patch like this? (With perhaps a better changelog?)
>>
>> -George
>>
>> ---
>> TSQ: Raise default static TSQ limit
>
On 04/15/2015 07:19 PM, Eric Dumazet wrote:
> On Wed, 2015-04-15 at 19:04 +0100, George Dunlap wrote:
>
>> Maybe you should stop wasting all of our time and just tell us what
>> you're thinking.
>
> I think you make me wasting my time.
>
> I already gave
On 04/16/2015 10:20 AM, Daniel Borkmann wrote:
> So mid term, it would be much more beneficial if you attempt fix the
> underlying driver issues that actually cause high tx completion delays,
> instead of reintroducing bufferbloat. So that we all can move forward
> and not backwards in time.
Yes,
On Thu, Apr 16, 2015 at 10:22 AM, David Laight wrote:
> ISTM that you are changing the wrong knob.
> You need to change something that affects the global amount of pending tx
> data,
> not the amount that can be buffered by a single connection.
Well it seems like the problem is that the global a
On 04/15/2015 07:17 PM, Eric Dumazet wrote:
> Do not expect me to fight bufferbloat alone. Be part of the challenge,
> instead of trying to get back to proven bad solutions.
I tried that. I wrote a description of what I thought the situation
was, so that you could correct me if my understanding w
On Thu, Apr 16, 2015 at 1:42 PM, Eric Dumazet wrote:
> On Thu, 2015-04-16 at 11:01 +0100, George Dunlap wrote:
>
>> He suggested that after he'd been prodded by 4 more e-mails in which two
>> of us guessed what he was trying to get at. That's what I was
>> comp
On Thu, Apr 9, 2015 at 5:36 PM, Stefano Stabellini
wrote:
> On Thu, 9 Apr 2015, Eric Dumazet wrote:
>> On Thu, 2015-04-09 at 16:46 +0100, Stefano Stabellini wrote:
>> > Hi all,
>> >
>> > I found a performance regression when running netperf -t TCP_MAERTS from
>> > an external host to a Xen VM on A
On 05/21/2015 06:57 PM, George Dunlap wrote:
> On 05/18/2015 08:16 PM, Don Zickus wrote:
>> I stumbled upon an AMD box that had the BIOS using a hardware counter.
>> Instead
>> of printing out a warning and continuing, it failed and blocked further perf
>> counter u
On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin wrote:
> No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
> workaround for the legacy hypervisor versions.
The interface wasn't an accident. In the most common case you'll want
to clear the bit anyway. In PV mode clearing
On 03/17/2014 05:05 PM, Jan Beulich wrote:
On 17.03.14 at 17:55, "H. Peter Anvin" wrote:
On 03/17/2014 05:19 AM, George Dunlap wrote:
On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin wrote:
No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
workaround for
On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel wrote:
> On 31/07/14 14:53, Ian Campbell wrote:
>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>
>>> include/xen/interface/domctl.h | 1090
>>>
>>
>> domctl is an stable toolstack only hyperviso
On 08/18/2015 04:55 PM, Dario Faggioli wrote:
> Hey everyone,
>
> So, as a followup of what we were discussing in this thread:
>
> [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest
> http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03241.html
>
> I started looki
On Thu, Aug 27, 2015 at 11:24 AM, George Dunlap
wrote:
> On 08/18/2015 04:55 PM, Dario Faggioli wrote:
>> Hey everyone,
>>
>> So, as a followup of what we were discussing in this thread:
>>
>> [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the gues
On 13/04/16 19:54, Luis R. Rodriguez wrote:
> On Wed, Apr 13, 2016 at 11:05:00AM +0100, George Dunlap wrote:
>> On Tue, Apr 12, 2016 at 11:12 PM, Luis R. Rodriguez
>> wrote:
>>> Also, x86 does have a history of short DT use. Just pointing that its there
>>> as
&
On 13/04/16 20:52, Luis R. Rodriguez wrote:
> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
>> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez wrote:
>>> So more to it, if the EFI entry already provides a way into Linux
>>> in a more streamlined fa
On 13/04/16 20:14, Luis R. Rodriguez wrote:
> On Wed, Apr 13, 2016 at 03:02:26PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Apr 13, 2016 at 08:50:10PM +0200, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 11:54:29AM +0200, Roger Pau Monné wrote:
On Fri, Apr 08, 2016 at 11:58:54PM +02
On 14/04/16 20:44, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote:
>> On 13/04/16 20:52, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
>>>> On Thu, Apr 7, 2016 at 7:51 PM, Luis
On 15/04/16 16:30, Luis R. Rodriguez wrote:
> On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote:
>> On 14/04/16 20:44, Luis R. Rodriguez wrote:
>>> No, I meant to ask, would it be possible to make booting HVMLite using EFI
>>> be optional ? That way if you a
Right -- so what was actually broken was the "does this register work"
check, which needs a non-enabled register.
Would it make sense to add a comment somewhere in the code saying that
you need a disabled event counter for the MSR check to work properly?
It's sort of implied but i
On 07/04/16 19:51, Luis R. Rodriguez wrote:
> While Andrew's position is right in that perhaps only Xen tools have to deal
> with the HVMLite specific entry, it would also still mean diverging from ARM's
> own EFI entry only position, which I'd like to clarify that ARM has no custom
> Xen entry, we
On Wed, Apr 6, 2016 at 3:40 AM, Luis R. Rodriguez wrote:
> A huge summary of the discussion over EFI boot option for HVMLite is now on a
> wiki [2], below I'll just provide the outline of the discussion. Consider
> this a
> request for more public review, feel free to take any of the items below
On 02/04/16 13:57, Andy Lutomirski wrote:
> On Fri, Apr 1, 2016 at 10:33 PM, Takashi Iwai wrote:
>> On Sat, 02 Apr 2016 00:28:31 +0200,
>> Luis R. Rodriguez wrote:
>>> If the former, could a we somehow detect an emulated device other than
>>> through
>>> this type of check ? Or could we *add* a c
On Tue, Apr 12, 2016 at 11:12 PM, Luis R. Rodriguez wrote:
> Also, x86 does have a history of short DT use. Just pointing that its there as
> an option as well. I'll Cc you on some thread about that.
I'm not sure how this is relevant to anything.
What we're talking about is how to get from Xen t
On Wed, Apr 13, 2016 at 11:15 AM, Matt Fleming wrote:
> For 1. we'd basically be using the PE/COFF file format with the EFI
> ABI as an OS agnostic boot protocol, but not as a full firmware
> runtime environment.
But we still have the issue here that the now the EFI entry point in
Linux has to fi
On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez wrote:
> So more to it, if the EFI entry already provides a way into Linux
> in a more streamlined fashion bringing it closer to the bare metal
> boot entry, why *would* we add another boot entry to x86, even if
> its small and self contained ?
We
On 09/23/2015 05:36 AM, Juergen Gross wrote:
> On 09/22/2015 06:22 PM, George Dunlap wrote:
>> On 09/22/2015 05:42 AM, Juergen Gross wrote:
>>> One other thing I just discovered: there are other consumers of the
>>> topology sibling masks (e.g. topology_sibling_cpumask(
On 09/22/2015 05:42 AM, Juergen Gross wrote:
> One other thing I just discovered: there are other consumers of the
> topology sibling masks (e.g. topology_sibling_cpumask()) as well.
>
> I think we would want to avoid any optimizations based on those in
> drivers as well, not only in the scheduler
On Fri, Sep 29, 2017 at 5:39 PM, Paolo Bonzini wrote:
> On 29/09/2017 17:47, Lai Jiangshan wrote:
>> Hello, all
>>
>> An interesting (at least to me) thinking came up to me when I found
>> that the lguest was removed. But I don't have enough knowledge
>> to find out the answer nor energy to implem
On Sat, Sep 30, 2017 at 4:39 AM, Paolo Bonzini wrote:
>
> - Lai Jiangshan ha scritto:
>> On Sat, Sep 30, 2017 at 12:39 AM, Paolo Bonzini wrote:
>> > On 29/09/2017 17:47, Lai Jiangshan wrote:
>> >> Hello, all
>> >>
>> >> An interesting (at least to me) thinking came up to me when I found
>> >
Commit-ID: a5ebe0ba3dff658c5286e8d5f20e4328f719d5a3
Gitweb: http://git.kernel.org/tip/a5ebe0ba3dff658c5286e8d5f20e4328f719d5a3
Author: George Dunlap
AuthorDate: Wed, 3 Apr 2013 15:46:28 +0100
Committer: Ingo Molnar
CommitDate: Sun, 21 Apr 2013 11:16:29 +0200
perf/x86: Check all MSRs
43 matches
Mail list logo
