Commit-ID: f92b7604149a55cb601fc0b52911b1e11f0f2514
Gitweb: http://git.kernel.org/tip/f92b7604149a55cb601fc0b52911b1e11f0f2514
Author: Imre Palik <im...@amazon.de>
AuthorDate: Fri, 21 Oct 2016 01:18:59 -0700
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 28 Oct 2
Commit-ID: f92b7604149a55cb601fc0b52911b1e11f0f2514
Gitweb: http://git.kernel.org/tip/f92b7604149a55cb601fc0b52911b1e11f0f2514
Author: Imre Palik
AuthorDate: Fri, 21 Oct 2016 01:18:59 -0700
Committer: Ingo Molnar
CommitDate: Fri, 28 Oct 2016 11:06:25 +0200
perf/x86/intel: Honour
From: Imre Palik <im...@amazon.de>
perf doesn't seem to honour the number of fixed counters specified by cpuid
leaf 0xa. It always assume that Intel CPUs have at least 3 fixed counters.
So if some of the fixed counters are masked out by the hypervisor, it still
tries to check/se
From: Imre Palik
perf doesn't seem to honour the number of fixed counters specified by cpuid
leaf 0xa. It always assume that Intel CPUs have at least 3 fixed counters.
So if some of the fixed counters are masked out by the hypervisor, it still
tries to check/set them.
This patch makes perf
From: Imre Palik <im...@amazon.de>
perf doesn't seem to honour the number of fixed counters specified by cpuid
leaf 0xa. It always assume that Intel CPUs have at least 3 fixed counters.
So if some of the fixed counters are masked out by the hypervisor, it still
tries to check/se
From: Imre Palik
perf doesn't seem to honour the number of fixed counters specified by cpuid
leaf 0xa. It always assume that Intel CPUs have at least 3 fixed counters.
So if some of the fixed counters are masked out by the hypervisor, it still
tries to check/set them.
This patch makes perf
hes. This behaviour is in line
with how connect() deals with the hotplug-status watch.
Signed-off-by: Imre Palik
Cc: Matt Wilson
---
drivers/net/xen-netback/xenbus.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
in
. This behaviour is in line
with how connect() deals with the hotplug-status watch.
Signed-off-by: Imre Palik im...@amazon.de
Cc: Matt Wilson m...@amazon.com
---
drivers/net/xen-netback/xenbus.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen
On 06/16/15 11:21, Peter Zijlstra wrote:
> On Mon, Jun 15, 2015 at 04:22:32PM +0200, Imre Palik wrote:
>> From: "Palik, Imre"
>>
>> Architectural performance monitoring version 1 doesn't support fixed
>> counters. Currently, even if a hypervisor ad
On 06/16/15 11:21, Peter Zijlstra wrote:
On Mon, Jun 15, 2015 at 04:22:32PM +0200, Imre Palik wrote:
From: Palik, Imre im...@amazon.de
Architectural performance monitoring version 1 doesn't support fixed
counters. Currently, even if a hypervisor advertises support for
architectural
t up based on the CPU model.
This patch ensures that perf honors the architectural performance
monitoring version returned by CPUID, and it only uses the fixed counters
for version two and above.
Some of the ideas in this patch are coming from Peter Zijlstra.
Signed-off-by: Imre Palik
Cc: Anthony Liguori
based on the CPU model.
This patch ensures that perf honors the architectural performance
monitoring version returned by CPUID, and it only uses the fixed counters
for version two and above.
Some of the ideas in this patch are coming from Peter Zijlstra.
Signed-off-by: Imre Palik im...@amazon.de
Cc
on the CPU model.
This patch ensures that perf honors the architectural performance monitoring
version returned by CPUID, and it only uses the fixed counters for version two
and above.
Some of the ideas in this patch are coming from Peter Zijlstra.
Signed-off-by: Imre Palik
Cc: Anthony Liguori
based on the CPU model.
This patch ensures that perf honors the architectural performance monitoring
version returned by CPUID, and it only uses the fixed counters for version two
and above.
Some of the ideas in this patch are coming from Peter Zijlstra.
Signed-off-by: Imre Palik im...@amazon.de
Cc
t up based on the CPU model.
This patch ensures that perf honors the architectural performance
monitoring version returned by CPUID, and it only uses the fixed counters
for version two and above.
Some of the ideas in this patch are coming from Peter Zijlstra.
Signed-off-by: Imre Palik
Cc: Anthony Liguori
On 06/04/15 15:29, Peter Zijlstra wrote:
> On Thu, Jun 04, 2015 at 02:30:37PM +0200, Imre Palik wrote:
>> The trouble is that the number of fixed counters is not taken into
>> account when scheduling the events, and the cpu model based event
>> constraints will favour fix
On 06/04/15 15:29, Peter Zijlstra wrote:
On Thu, Jun 04, 2015 at 02:30:37PM +0200, Imre Palik wrote:
The trouble is that the number of fixed counters is not taken into
account when scheduling the events, and the cpu model based event
constraints will favour fixed counters. So perf tries
based on the CPU model.
This patch ensures that perf honors the architectural performance
monitoring version returned by CPUID, and it only uses the fixed counters
for version two and above.
Some of the ideas in this patch are coming from Peter Zijlstra.
Signed-off-by: Imre Palik im...@amazon.de
Cc
On 06/04/15 13:49, Peter Zijlstra wrote:
> On Thu, Jun 04, 2015 at 12:35:08PM +0200, Imre Palik wrote:
>> On 06/03/15 10:36, Peter Zijlstra wrote:
>>> Further, the Intel Arch PerfMon v2 spec actually specifies there to be 3
>>> fixed function counters.
>>>
On 06/03/15 10:36, Peter Zijlstra wrote:
> On Wed, Jun 03, 2015 at 10:03:48AM +0200, Imre Palik wrote:
>> From: "Palik, Imre"
>>
>> perf doesn't seem to honor the number of fixed counters specified by cpuid
>> leaf 0xa. It always assume that intel CPUs hav
On 06/03/15 10:36, Peter Zijlstra wrote:
On Wed, Jun 03, 2015 at 10:03:48AM +0200, Imre Palik wrote:
From: Palik, Imre im...@amazon.de
perf doesn't seem to honor the number of fixed counters specified by cpuid
leaf 0xa. It always assume that intel CPUs have at least 3 fixed counters.
So
On 06/04/15 13:49, Peter Zijlstra wrote:
On Thu, Jun 04, 2015 at 12:35:08PM +0200, Imre Palik wrote:
On 06/03/15 10:36, Peter Zijlstra wrote:
Further, the Intel Arch PerfMon v2 spec actually specifies there to be 3
fixed function counters.
So anything that says it is v2+ and does not have
is is good for testing the masking code in the
hypervisor, but not so nice otherwise.
This patch makes perf pehave somewhat nicer when the number of fixed
counters is less than three.
Signed-off-by: Imre Palik
Cc: Anthony Liguori
---
arch/x86/kernel/cpu/perf_event.c |2 ++
arch/x86/
. This is good for testing the masking code in the
hypervisor, but not so nice otherwise.
This patch makes perf pehave somewhat nicer when the number of fixed
counters is less than three.
Signed-off-by: Imre Palik im...@amazon.de
Cc: Anthony Liguori aligu...@amazon.com
---
arch/x86/kernel/cpu/perf_event.c
the change.
Cc: Anthony Liguori
Signed-off-by: Imre Palik
---
drivers/net/xen-netback/common.h|4 +++
drivers/net/xen-netback/interface.c |1 +
drivers/net/xen-netback/netback.c |4 +--
drivers/net/xen-netback/xenbus.c| 57 +++
4 files c
the change.
Cc: Anthony Liguori aligu...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
drivers/net/xen-netback/common.h|4 +++
drivers/net/xen-netback/interface.c |1 +
drivers/net/xen-netback/netback.c |4 +--
drivers/net/xen-netback/xenbus.c| 57
On 03/17/15 12:17, Wei Liu wrote:
> On Fri, Mar 13, 2015 at 01:51:05PM +0100, Imre Palik wrote:
>> From: "Palik, Imre"
>>
>> With the current netback, the bandwidth limiter's parameters are only
>> settable during vif setup time. This patch register a
On 03/17/15 12:17, Wei Liu wrote:
On Fri, Mar 13, 2015 at 01:51:05PM +0100, Imre Palik wrote:
From: Palik, Imre im...@amazon.de
With the current netback, the bandwidth limiter's parameters are only
settable during vif setup time. This patch register a watch on them, and
thus makes them
the change.
Cc: Anthony Liguori
Signed-off-by: Imre Palik
---
drivers/net/xen-netback/common.h|4 ++
drivers/net/xen-netback/interface.c |1 +
drivers/net/xen-netback/netback.c |4 +-
drivers/net/xen-netback/xenbus.c| 73 +++
4 files c
the change.
Cc: Anthony Liguori aligu...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
drivers/net/xen-netback/common.h|4 ++
drivers/net/xen-netback/interface.c |1 +
drivers/net/xen-netback/netback.c |4 +-
drivers/net/xen-netback/xenbus.c| 73
On 02/26/15 17:34, David Miller wrote:
> From: Imre Palik
> Date: Thu, 26 Feb 2015 11:19:25 +0100
>
>> If you are looking for peculiarities in my setup then here they are:
>> I am on 4k pages, and perf is not working :-(
>> (I am trying to fix those too, but that is f
On 02/26/15 17:34, David Miller wrote:
From: Imre Palik im...@amazon.de
Date: Thu, 26 Feb 2015 11:19:25 +0100
If you are looking for peculiarities in my setup then here they are:
I am on 4k pages, and perf is not working :-(
(I am trying to fix those too, but that is far from being a low
On 02/23/15 17:06, Florian Westphal wrote:
> Imre Palik wrote:
>> The netfilter code is made with flexibility instead of performance in mind.
>> So when all we want is to pass packets between different interfaces, the
>> performance penalty of hitting netfilter code can be co
On 02/23/15 17:06, Florian Westphal wrote:
Imre Palik imrep@gmail.com wrote:
The netfilter code is made with flexibility instead of performance in mind.
So when all we want is to pass packets between different interfaces, the
performance penalty of hitting netfilter code can
the bridge.
This change makes it possible to disable netfilter on a per bridge basis.
In the case interesting to us, this can lead to more than 15% speedup
compared to the case when only bridge-iptables is disabled.
Cc: Anthony Liguori
Signed-off-by: Imre Palik
---
net/bridge/br_device.c |
On 02/13/15 20:03, Florian Westphal wrote:
> Imre Palik wrote:
>> The trouble is that there are some bridges (with low traffic) where I need
>> netfilter, and some other bridges (carrying lots of traffic), where I don't.
>> Being able to set things up on a per bridge basi
for the bridge.
This change makes it possible to disable netfilter on a per bridge basis.
In the case interesting to us, this can lead to more than 15% speedup
compared to the case when only bridge-iptables is disabled.
Cc: Anthony Liguori aligu...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
On 02/13/15 20:03, Florian Westphal wrote:
Imre Palik imrep@gmail.com wrote:
The trouble is that there are some bridges (with low traffic) where I need
netfilter, and some other bridges (carrying lots of traffic), where I don't.
Being able to set things up on a per bridge basis
On 02/13/15 17:37, Florian Westphal wrote:
> Imre Palik wrote:
>> On 02/11/15 23:29, David Miller wrote:
>>> If I apply this, someone is going to try to submit a patch for every
>>> damn protocol layer to add a stupid hack like this.
>>
>> Actually this is
On 02/11/15 23:29, David Miller wrote:
> From: Imre Palik
> Date: Tue, 10 Feb 2015 10:32:24 +0100
>
>> From: "Palik, Imre"
>>
>> The netfilter code is made with flexibility instead of performance in mind.
>> So when all we want is to pass packets betwe
On 02/11/15 23:29, David Miller wrote:
From: Imre Palik imrep@gmail.com
Date: Tue, 10 Feb 2015 10:32:24 +0100
From: Palik, Imre im...@amazon.de
The netfilter code is made with flexibility instead of performance in mind.
So when all we want is to pass packets between different
On 02/13/15 17:37, Florian Westphal wrote:
Imre Palik imrep@gmail.com wrote:
On 02/11/15 23:29, David Miller wrote:
If I apply this, someone is going to try to submit a patch for every
damn protocol layer to add a stupid hack like this.
Actually this is one of those patches
the bridge.
This change makes it possible to disable netfilter both on a per bridge basis,
or for the whole bridging subsystem. In the case interesting to us, this can
lead to more than 10% speedup compared to the case when only bridge-iptables
are disabled.
Cc: Anthony Liguori
Signed-off-by:
Signed-off-by: Imre Palik im...@amazon.de
---
net/bridge/br_forward.c |3 +--
net/bridge/br_input.c |3 +--
net/bridge/br_netfilter.c | 48 +
net/bridge/br_private.h |9 +
net/bridge/br_sysfs_br.c | 23
gle thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
thread creation can cause.
Reported-by: Matt Wilson
Cc: Matt Wilson
Signed-off-by: Imre Palik
---
kernel/audit_tree.c | 88 +++
1 file c
a single thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
thread creation can cause.
Reported-by: Matt Wilson m...@amazon.com
Cc: Matt Wilson m...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
kernel/audit_tree.c | 88
gle thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
thread creation can cause.
Reported-by: Matt Wilson
Cc: Matt Wilson
Signed-off-by: Imre Palik
---
kernel/audit_tree.c | 86 ++-
1 file c
On 01/13/15 02:47, Paul Moore wrote:
> On Monday, January 12, 2015 09:11:21 AM Imre Palik wrote:
>> On 01/08/15 22:53, Paul Moore wrote:
>>> On Tuesday, January 06, 2015 03:51:20 PM Imre Palik wrote:
>>>> From: "Palik, Imre"
>>>>
>>>&
On 01/13/15 02:47, Paul Moore wrote:
On Monday, January 12, 2015 09:11:21 AM Imre Palik wrote:
On 01/08/15 22:53, Paul Moore wrote:
On Tuesday, January 06, 2015 03:51:20 PM Imre Palik wrote:
From: Palik, Imre im...@amazon.de
When file auditing is enabled, during a low memory situation
a single thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
thread creation can cause.
Reported-by: Matt Wilson m...@amazon.com
Cc: Matt Wilson m...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
kernel/audit_tree.c | 86
urce, thus it should have
higher rating.
This patch decreases the rating of the Xen clocksource in Dom0s to 275.
Which is half-way between the rating of the TSC clocksource (300) and the
hpet clocksource (250).
Cc: Anthony Liguori
Signed-off-by: Imre Palik
---
arch/x86/xen/time.c |4
1 file
clocksource, thus it should have
higher rating.
This patch decreases the rating of the Xen clocksource in Dom0s to 275.
Which is half-way between the rating of the TSC clocksource (300) and the
hpet clocksource (250).
Cc: Anthony Liguori aligu...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
On 01/08/15 22:53, Paul Moore wrote:
> On Tuesday, January 06, 2015 03:51:20 PM Imre Palik wrote:
>> From: "Palik, Imre"
>>
>> When file auditing is enabled, during a low memory situation, a memory
>> allocation with __GFP_FS can lead to pruning the ino
On 01/08/15 22:53, Paul Moore wrote:
On Tuesday, January 06, 2015 03:51:20 PM Imre Palik wrote:
From: Palik, Imre im...@amazon.de
When file auditing is enabled, during a low memory situation, a memory
allocation with __GFP_FS can lead to pruning the inode cache. Which can,
in turn lead
On 01/07/15 17:30, Ian Campbell wrote:
> On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote:
>> From: "Palik, Imre"
>>
>> In Dom0's the use of the TSC clocksource (whenever it is stable enough to
>> be used) instead of the Xen clocksource should not cause
On 01/07/15 17:30, Ian Campbell wrote:
On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote:
From: Palik, Imre im...@amazon.de
In Dom0's the use of the TSC clocksource (whenever it is stable enough to
be used) instead of the Xen clocksource should not cause any issues, as
Dom0 VMs never live
urce, thus it should have
higher rating.
Cc: Anthony Liguori
Signed-off-by: Imre Palik
---
arch/x86/xen/time.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..c768726 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -487
clocksource, thus it should have
higher rating.
Cc: Anthony Liguori aligu...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
arch/x86/xen/time.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..c768726 100644
--- a/arch/x86/xen
Liguori
Signed-off-by: Imre Palik
---
drivers/net/xen-netback/xenbus.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index efbaf2a..794204e 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbu
gle thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand thread
creation can cause.
Reported-by: Matt Wilson
Cc: Matt Wilson
Signed-off-by: Imre Palik
---
kernel/audit_tree.c | 91 +++
1 file c
a single thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand thread
creation can cause.
Reported-by: Matt Wilson m...@amazon.com
Cc: Matt Wilson m...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
kernel/audit_tree.c | 91
aligu...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
drivers/net/xen-netback/xenbus.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index efbaf2a..794204e 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b
d it would need some rewrite of the code to limit the
amount of threads possibly spawned.
Reported-by: Matt Wilson
Cc: Matt Wilson
Cc: Al Viro
Signed-off-by: Imre Palik
---
kernel/audit_tree.c | 53 ++-
1 file changed, 35 insertions(+), 18
, and it would need some rewrite of the code to limit the
amount of threads possibly spawned.
Reported-by: Matt Wilson m...@amazon.com
Cc: Matt Wilson m...@amazon.com
Cc: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Imre Palik im...@amazon.de
---
kernel/audit_tree.c | 53
d it would need some rewrite of the code to limit the
amount of threads possibly spawned.
Reported-by: Matt Wilson
Cc: Matt Wilson
Cc: Al Viro
Signed-off-by: Imre Palik
---
kernel/audit_tree.c | 53 ++-
1 file changed, 35 insertions(+), 18
, and it would need some rewrite of the code to limit the
amount of threads possibly spawned.
Reported-by: Matt Wilson m...@amazon.com
Cc: Matt Wilson m...@amazon.com
Cc: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Imre Palik im...@amazon.de
---
kernel/audit_tree.c | 53
d it would need some rewrite of the code to limit the
amount of threads possibly spawned.
Reported-by: Matt Wilson
Cc: Matt Wilson
Signed-off-by: Imre Palik
---
kernel/audit_tree.c | 53 ++-
1 file changed, 35 insertions(+), 18 deletions(-)
, and it would need some rewrite of the code to limit the
amount of threads possibly spawned.
Reported-by: Matt Wilson m...@amazon.com
Cc: Matt Wilson m...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
kernel/audit_tree.c | 53 ++-
1 file
On 09/08/14 15:38, Lars wrote:
On Mon, Sep 08, 2014 at 03:05:28PM +0200, Imre Palik wrote:
On 09/07/14 11:58, Lars wrote:
On Fri, Sep 05, 2014 at 08:41:18PM +0200, Imre Palik wrote:
From: "Palik, Imre"
If the drbd backing device is a new device mapper device (e.g., a
dm-line
On 09/08/14 15:38, Lars wrote:
On Mon, Sep 08, 2014 at 03:05:28PM +0200, Imre Palik wrote:
On 09/07/14 11:58, Lars wrote:
On Fri, Sep 05, 2014 at 08:41:18PM +0200, Imre Palik wrote:
From: Palik, Imre im...@amazon.de
If the drbd backing device is a new device mapper device (e.g., a
dm-linear
On 09/07/14 11:58, Lars wrote:
On Fri, Sep 05, 2014 at 08:41:18PM +0200, Imre Palik wrote:
From: "Palik, Imre"
If the drbd backing device is a new device mapper device (e.g., a
dm-linear mapping of an existing block device that contains data), the
counters are initially 0 e
On 09/07/14 11:58, Lars wrote:
On Fri, Sep 05, 2014 at 08:41:18PM +0200, Imre Palik wrote:
From: Palik, Imre im...@amazon.de
If the drbd backing device is a new device mapper device (e.g., a
dm-linear mapping of an existing block device that contains data), the
counters are initially 0 even
rbd device
or the backing device.
The patch disables throttling, as long as only resync is responsible
for disk activity on a freshly created device.
Reported-by: Mikhail Sugakov
Cc: Matt Wilson
Signed-off-by: Imre Palik
---
drivers/block/drbd/drbd_int.h |4 ++--
drivers/block/drbd/drbd_
device
or the backing device.
The patch disables throttling, as long as only resync is responsible
for disk activity on a freshly created device.
Reported-by: Mikhail Sugakov msuga...@amazon.de
Cc: Matt Wilson m...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
drivers/block/drbd
rbd device
or the backing device.
The patch disables throttling, as long as only resync is responsible
for disk activity on a freshly created device.
Reported-by: Mikhail Sugakov
Cc: Matt Wilson
Signed-off-by: Imre Palik
---
drivers/block/drbd/drbd_main.c |3 ++-
drivers/block/drbd/drbd_
device
or the backing device.
The patch disables throttling, as long as only resync is responsible
for disk activity on a freshly created device.
Reported-by: Mikhail Sugakov msuga...@amazon.de
Cc: Matt Wilson m...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
drivers/block/drbd
rbd device
or the backing device.
The patch disables throttling, as long as only resync is responsible
for disk activity on a freshly created device.
Reported-by: Mikhail Sugakov
Cc: Matt Wilson
Signed-off-by: Imre Palik
---
drivers/block/drbd/drbd_receiver.c |3 ++-
1 file changed, 2 insert
device
or the backing device.
The patch disables throttling, as long as only resync is responsible
for disk activity on a freshly created device.
Reported-by: Mikhail Sugakov msuga...@amazon.de
Cc: Matt Wilson m...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
drivers/block/drbd
78 matches
Mail list logo
