On Wed, 29 Mar 2017 11:12:26 -0700 Matthew Wilcox <wi...@infradead.org> wrote:
> On Wed, Mar 29, 2017 at 11:19:49AM +0200, Peter Zijlstra wrote:
> > On Wed, Mar 29, 2017 at 10:59:28AM +0200, Jesper Dangaard Brouer wrote:
> > > On Wed, 29 Mar 2017 10:12:19 +0200
&
On Wed, 29 Mar 2017 11:12:26 -0700 Matthew Wilcox wrote:
> On Wed, Mar 29, 2017 at 11:19:49AM +0200, Peter Zijlstra wrote:
> > On Wed, Mar 29, 2017 at 10:59:28AM +0200, Jesper Dangaard Brouer wrote:
> > > On Wed, 29 Mar 2017 10:12:19 +0200
> > > Peter Zijlstra
On Tue, 28 Mar 2017 23:11:22 +0200
Frederic Weisbecker <fweis...@gmail.com> wrote:
> On Tue, Mar 28, 2017 at 05:23:03PM +0200, Jesper Dangaard Brouer wrote:
> > On Tue, 28 Mar 2017 16:34:36 +0200
> > Frederic Weisbecker <fweis...@gmail.com> wrote:
> >
> &g
On Tue, 28 Mar 2017 23:11:22 +0200
Frederic Weisbecker wrote:
> On Tue, Mar 28, 2017 at 05:23:03PM +0200, Jesper Dangaard Brouer wrote:
> > On Tue, 28 Mar 2017 16:34:36 +0200
> > Frederic Weisbecker wrote:
> >
> > > On Tue, Mar 28, 2017 at 10:14:03AM +0200
On Wed, 29 Mar 2017 10:12:19 +0200
Peter Zijlstra <pet...@infradead.org> wrote:
> On Mon, Mar 27, 2017 at 09:58:17AM -0700, Matthew Wilcox wrote:
> > On Mon, Mar 27, 2017 at 05:15:00PM +0200, Jesper Dangaard Brouer wrote:
> > > And I also verified it worked:
> &g
On Wed, 29 Mar 2017 10:12:19 +0200
Peter Zijlstra wrote:
> On Mon, Mar 27, 2017 at 09:58:17AM -0700, Matthew Wilcox wrote:
> > On Mon, Mar 27, 2017 at 05:15:00PM +0200, Jesper Dangaard Brouer wrote:
> > > And I also verified it worked:
> > >
> > > 0.63
On Tue, 28 Mar 2017 16:34:36 +0200
Frederic Weisbecker <fweis...@gmail.com> wrote:
> On Tue, Mar 28, 2017 at 10:14:03AM +0200, Jesper Dangaard Brouer wrote:
> >
> > (While evaluating some changes to the page allocator) I ran into an
> > issue with ksoftirqd gett
On Tue, 28 Mar 2017 16:34:36 +0200
Frederic Weisbecker wrote:
> On Tue, Mar 28, 2017 at 10:14:03AM +0200, Jesper Dangaard Brouer wrote:
> >
> > (While evaluating some changes to the page allocator) I ran into an
> > issue with ksoftirqd getting too much CPU sched time
hange moved updating cpustat[CPUTIME_SOFTIRQ] here.
Before it got updated by account_other_time() which gets invoked from
irqtime_account_process_tick().
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
_SOFTIRQ] here.
Before it got updated by account_other_time() which gets invoked from
irqtime_account_process_tick().
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
On Tue, 28 Mar 2017 18:34:52 +0800
Wanpeng Li <kernel...@gmail.com> wrote:
> 2017-03-28 16:14 GMT+08:00 Jesper Dangaard Brouer <bro...@redhat.com>:
> >
> > (While evaluating some changes to the page allocator) I ran into an
> > issue with ksoftirqd getting t
On Tue, 28 Mar 2017 18:34:52 +0800
Wanpeng Li wrote:
> 2017-03-28 16:14 GMT+08:00 Jesper Dangaard Brouer :
> >
> > (While evaluating some changes to the page allocator) I ran into an
> > issue with ksoftirqd getting too much CPU sched time.
> >
> > I bisected
rs).
A related symptom is that ksoftirqd no longer get accounted in top.
$ grep CONFIG_IRQ_TIME_ACCOUNTING .config
CONFIG_IRQ_TIME_ACCOUNTING=y
Full .config uploaded here[2]:
[2]
http://people.netfilter.org/hawk/kconfig/config02-bisect-softirq-a499a5a14dbd
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
ploaded here[2]:
[2]
http://people.netfilter.org/hawk/kconfig/config02-bisect-softirq-a499a5a14dbd
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
On Tue, 7 Feb 2017 14:23:23 -0700
Jonathan Corbet <cor...@lwn.net> wrote:
> On Tue, 7 Feb 2017 21:51:49 +0100
> Jesper Dangaard Brouer <bro...@redhat.com> wrote:
>
> > I sounds like Daniel (see other email) have bigger plans for what
> > Documentation/BPF/ sh
On Tue, 7 Feb 2017 14:23:23 -0700
Jonathan Corbet wrote:
> On Tue, 7 Feb 2017 21:51:49 +0100
> Jesper Dangaard Brouer wrote:
>
> > I sounds like Daniel (see other email) have bigger plans for what
> > Documentation/BPF/ should contain. E.g. consolidating
> &g
On Tue, 07 Feb 2017 17:43:38 +0100
Daniel Borkmann <dan...@iogearbox.net> wrote:
> Hi Jesper,
>
> On 02/07/2017 03:30 PM, Jesper Dangaard Brouer wrote:
> > Question: What kernel tree should this go into???
> >
> > If going through Jonathan Corbet, will it
On Tue, 07 Feb 2017 17:43:38 +0100
Daniel Borkmann wrote:
> Hi Jesper,
>
> On 02/07/2017 03:30 PM, Jesper Dangaard Brouer wrote:
> > Question: What kernel tree should this go into???
> >
> > If going through Jonathan Corbet, will it appear sooner here???
> >
On Tue, 7 Feb 2017 09:46:08 -0700
Jonathan Corbet <cor...@lwn.net> wrote:
> On Tue, 7 Feb 2017 17:09:08 +0100
> Jesper Dangaard Brouer <bro...@redhat.com> wrote:
>
> > > > Question: What kernel tree should this go into???
> > > >
> > > >
On Tue, 7 Feb 2017 09:46:08 -0700
Jonathan Corbet wrote:
> On Tue, 7 Feb 2017 17:09:08 +0100
> Jesper Dangaard Brouer wrote:
>
> > > > Question: What kernel tree should this go into???
> > > >
> > > > If going through Jonathan Corbet,
On Tue, 7 Feb 2017 08:37:17 -0700
Jonathan Corbet <cor...@lwn.net> wrote:
> On Tue, 07 Feb 2017 15:30:11 +0100
> Jesper Dangaard Brouer <bro...@redhat.com> wrote:
>
> > Question: What kernel tree should this go into???
> >
> > If going through Jona
On Tue, 7 Feb 2017 08:37:17 -0700
Jonathan Corbet wrote:
> On Tue, 07 Feb 2017 15:30:11 +0100
> Jesper Dangaard Brouer wrote:
>
> > Question: What kernel tree should this go into???
> >
> > If going through Jonathan Corbet, will it appear sooner here???
> >
It is worth mentioning BCC (BPF Compiler Collection) in-order
to direct developers into that community.
Reviewed-by: Alexander Alemayhu <alexan...@alemayhu.com>
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
Documentation/bpf/bcc_tool_chai
It is worth mentioning BCC (BPF Compiler Collection) in-order
to direct developers into that community.
Reviewed-by: Alexander Alemayhu
Signed-off-by: Jesper Dangaard Brouer
---
Documentation/bpf/bcc_tool_chain.rst | 37 ++
Documentation/bpf/index.rst
com> for improving
this document with areas eBFP is used in and early review.
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
Documentation/bpf/index.rst | 66 +++
Documentation/index.rst |1 +
2 files changed, 67 insertions(+)
with areas eBFP is used in and early review.
Signed-off-by: Jesper Dangaard Brouer
---
Documentation/bpf/index.rst | 66 +++
Documentation/index.rst |1 +
2 files changed, 67 insertions(+)
create mode 100644 Documentation/bpf/index.rst
diff --git
Describe what eBPF maps are, how to create them, and how to
interact with them.
Thanks to Quentin Monnet <quentin.mon...@6wind.com> for improving
this document by fixing many typos and early review.
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
Documentation/bpf/e
Describe what eBPF maps are, how to create them, and how to
interact with them.
Thanks to Quentin Monnet for improving
this document by fixing many typos and early review.
Signed-off-by: Jesper Dangaard Brouer
---
Documentation/bpf/ebpf_maps.rst | 255
The purpose is to help choose the right map type based on the
individual use-case.
To start with, only BPF_MAP_TYPE_ARRAY is described. It is the plan
that all types should have descriptions here.
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
Documentation/bpf/ebpf_ma
x.net>
Quentin Monnet <quentin.mon...@6wind.com>
---
Jesper Dangaard Brouer (4):
doc/bpf: start eBPF documentation tree bpf/
doc/bpf: document interacting with eBPF maps
doc/bpf: describes the different types of eBPF maps available
doc/bpf: describe BCC the
The purpose is to help choose the right map type based on the
individual use-case.
To start with, only BPF_MAP_TYPE_ARRAY is described. It is the plan
that all types should have descriptions here.
Signed-off-by: Jesper Dangaard Brouer
---
Documentation/bpf/ebpf_maps.rst |3
/tree/master/kernel/Documentation
Thanks to the following people, who have already reviewed and fixed
earlier versions of this documentation on the IOvisor mailing-list:
Alexander Alemayhu
Alexei Starovoitov
Daniel Borkmann
Quentin Monnet
---
Jesper Dangaard Brouer (4):
doc/bpf: start
tistics(preferred_zone, zone, gfp_flags);
Word-of-warning: The zone_statistics() call changed number of
parameters in commit 41b6167e8f74 ("mm: get rid of __GFP_OTHER_NODE").
(Not sure what tree you are based on)
> + }
> + local_irq_restore(flags);
> + return page
, gfp_flags);
Word-of-warning: The zone_statistics() call changed number of
parameters in commit 41b6167e8f74 ("mm: get rid of __GFP_OTHER_NODE").
(Not sure what tree you are based on)
> + }
> + local_irq_restore(flags);
> + return page;
> +}
--
Best re
> It shows a roughly 50-60% reduction in the cost of allocating pages.
> The free paths are not improved as much but relatively little can be batched
> there. It's not quite as fast as it could be but taking further shortcuts
> would require making a lot of assumptions about the state of the page and
> the context of the caller.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
l-odr0-4096264.62 ( 0.00%) 181.54 (
> 31.40%)
> Ameantotal-odr0-8192267.00 ( 0.00%) 185.00 (
> 30.71%)
> Ameantotal-odr0-16384 268.00 ( 0.00%) 186.46 (
> 30.42%)
>
> It shows a roughly 50-60% reduction
On Wed, 11 Jan 2017 13:44:20 +0100
Jesper Dangaard Brouer <bro...@redhat.com> wrote:
> On Mon, 9 Jan 2017 16:35:17 + Mel Gorman <mgor...@techsingularity.net>
> wrote:
>
> > The following is results from a page allocator micro-benchmark. Only
> > order-0 i
On Wed, 11 Jan 2017 13:44:20 +0100
Jesper Dangaard Brouer wrote:
> On Mon, 9 Jan 2017 16:35:17 + Mel Gorman
> wrote:
>
> > The following is results from a page allocator micro-benchmark. Only
> > order-0 is interesting as higher orders do not use the per-cpu a
see below [2]]
> Signed-off-by: Mel Gorman <mgor...@techsingularity.net>
> Acked-by: Hillf Danton <hillf...@alibaba-inc.com>
Acked-by: Jesper Dangaard Brouer <bro...@redhat.com>
[1] https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm/bench
-
Best regard
el Gorman
> Acked-by: Hillf Danton
Acked-by: Jesper Dangaard Brouer
[1] https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm/bench
-
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
[2] Expected
ingularity.net>
Acked-by: Jesper Dangaard Brouer <bro...@redhat.com>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
es has to do the preparation steps multiple times. This patch
> structures __alloc_pages_nodemask such that it's relatively easy to build
> a bulk order-0 page allocator. There is no functional change.
>
> Signed-off-by: Mel Gorman
Acked-by: Jesper Dangaard Brouer
--
Best regards,
rrupts multiple
> times. This patch structures buffere_rmqueue such that it's relatively
> easy to build a bulk order-0 page allocator. There is no functional
> change.
>
> Signed-off-by: Mel Gorman <mgor...@techsingularity.net>
Acked-by: Jesper Dangaard Brouer <bro...@
h structures buffere_rmqueue such that it's relatively
> easy to build a bulk order-0 page allocator. There is no functional
> change.
>
> Signed-off-by: Mel Gorman
Acked-by: Jesper Dangaard Brouer
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at
ocalhost
> and between physical server/clients where other costs dominate. It's
> possible that this will only be noticable on very high speed networks.
The networking results highly depend on NIC drivers. As you mention in
the cover-letter, (1) some drivers (e.g mlx4) alloc high-order pages t
rver/clients where other costs dominate. It's
> possible that this will only be noticable on very high speed networks.
The networking results highly depend on NIC drivers. As you mention in
the cover-letter, (1) some drivers (e.g mlx4) alloc high-order pages to
work-around order-0 page
t_zid_vm_events(PGALLOC, zone_idx(zone), alloced);
> + zone_statistics(zone, zone, gfp_mask);
> +
> + local_irq_restore(flags);
> +
> + return alloced;
> +
> +failed:
> + page = __alloc_pages_nodemask(gfp_mask, order, zonelist, nodemask);
> + if (page) {
> + alloced++;
> + list_add(>lru, alloc_list);
> + }
> +
> + return alloced;
> +}
> +EXPORT_SYMBOL(__alloc_pages_bulk_nodemask);
> +
> +/*
> * Common helper functions.
> */
> unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
istics(zone, zone, gfp_mask);
> +
> + local_irq_restore(flags);
> +
> + return alloced;
> +
> +failed:
> + page = __alloc_pages_nodemask(gfp_mask, order, zonelist, nodemask);
> + if (page) {
> + alloced++;
> + list_add(>lru, alloc_list);
> + }
> +
> + return alloced;
> +}
> +EXPORT_SYMBOL(__alloc_pages_bulk_nodemask);
> +
> +/*
> * Common helper functions.
> */
> unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
:
https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/
You can download the tarballs from:
https://kernel.org/pub/linux/utils/kernel/ipvsadm/
Git tree:
git://git.kernel.org/pub/scm/utils/kernel/ipvsadm/ipvsadm.git
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel
:
https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/
You can download the tarballs from:
https://kernel.org/pub/linux/utils/kernel/ipvsadm/
Git tree:
git://git.kernel.org/pub/scm/utils/kernel/ipvsadm/ipvsadm.git
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel
On Thu, 8 Dec 2016 15:11:01 +
Mel Gorman <mgor...@techsingularity.net> wrote:
> On Thu, Dec 08, 2016 at 03:48:13PM +0100, Jesper Dangaard Brouer wrote:
> > On Thu, 8 Dec 2016 11:06:56 +
> > Mel Gorman <mgor...@techsingularity.net> wrote:
> >
> &g
On Thu, 8 Dec 2016 15:11:01 +
Mel Gorman wrote:
> On Thu, Dec 08, 2016 at 03:48:13PM +0100, Jesper Dangaard Brouer wrote:
> > On Thu, 8 Dec 2016 11:06:56 +
> > Mel Gorman wrote:
> >
> > > On Thu, Dec 08, 2016 at 11:43:08AM +0100, Jesper Dangaard Br
On Thu, 8 Dec 2016 11:06:56 +
Mel Gorman <mgor...@techsingularity.net> wrote:
> On Thu, Dec 08, 2016 at 11:43:08AM +0100, Jesper Dangaard Brouer wrote:
> > > That's expected. In the initial sniff-test, I saw negligible packet loss.
> > > I'm waiting to see what th
On Thu, 8 Dec 2016 11:06:56 +
Mel Gorman wrote:
> On Thu, Dec 08, 2016 at 11:43:08AM +0100, Jesper Dangaard Brouer wrote:
> > > That's expected. In the initial sniff-test, I saw negligible packet loss.
> > > I'm waiting to see what the full set of network tests look li
On Thu, 8 Dec 2016 09:18:06 +
Mel Gorman <mgor...@techsingularity.net> wrote:
> On Thu, Dec 08, 2016 at 09:22:31AM +0100, Jesper Dangaard Brouer wrote:
> > On Wed, 7 Dec 2016 23:25:31 +
> > Mel Gorman <mgor...@techsingularity.net> wrote:
> >
> &g
On Thu, 8 Dec 2016 09:18:06 +
Mel Gorman wrote:
> On Thu, Dec 08, 2016 at 09:22:31AM +0100, Jesper Dangaard Brouer wrote:
> > On Wed, 7 Dec 2016 23:25:31 +
> > Mel Gorman wrote:
> >
> > > On Wed, Dec 07, 2016 at 09:19:58PM +, Mel Gorman wrote:
[2] https://github.com/gormanm/mmtests/commit/7f16226577b
[3] https://git.kernel.org/davem/net-next/c/363dc73acacb
[4] https://github.com/gormanm/mmtests/commit/777d1f5cd08
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
tests/commit/7f16226577b
[3] https://git.kernel.org/davem/net-next/c/363dc73acacb
[4] https://github.com/gormanm/mmtests/commit/777d1f5cd08
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
On Thu, 01 Dec 2016 23:17:48 +0100
Paolo Abeni <pab...@redhat.com> wrote:
> On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote:
> > (Cc. netdev, we might have an issue with Paolo's UDP accounting and
> > small socket queues)
> >
> > On Wed, 30 Nov 2
On Thu, 01 Dec 2016 23:17:48 +0100
Paolo Abeni wrote:
> On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote:
> > (Cc. netdev, we might have an issue with Paolo's UDP accounting and
> > small socket queues)
> >
> > On Wed, 30 Nov 2016 16:35:20
pRcvbufErrors 99 0.0
IpExtInOctets 852713328 0.0
IpExtOutOctets 852713328 0.0
IpExtInNoECTPkts810563 0.0
And nstat is also much better with only 99 drop/sec.
--
Best reg
0.0
IpExtInOctets 852713328 0.0
IpExtOutOctets 852713328 0.0
IpExtInNoECTPkts810563 0.0
And nstat is also much better with only 99 drop/sec.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Prin
On Wed, 30 Nov 2016 14:06:15 +
Mel Gorman <mgor...@techsingularity.net> wrote:
> On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote:
> >
> > On Sun, 27 Nov 2016 13:19:54 + Mel Gorman <mgor...@techsingularity.net>
> > wrote:
>
On Wed, 30 Nov 2016 14:06:15 +
Mel Gorman wrote:
> On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote:
> >
> > On Sun, 27 Nov 2016 13:19:54 + Mel Gorman
> > wrote:
> >
> > [...]
> > > SLUB has been the default sm
This will also help performance of NIC driver that allocator
higher-order pages for their RX-ring queue (and chop it up for MTU).
I do like this patch, even-though I'm working on moving drivers away
from allocation these high-order pages.
Acked-by: Jesper Dangaard Brouer <bro...@redhat.com&g
NIC driver that allocator
higher-order pages for their RX-ring queue (and chop it up for MTU).
I do like this patch, even-though I'm working on moving drivers away
from allocation these high-order pages.
Acked-by: Jesper Dangaard Brouer
[...]
> This is the result from netperf running
skb_array.h
[...]
>
> +static inline int skb_array_ll_produce(struct skb_array_ll *a, struct
> sk_buff *skb)
> +{
> + return __ptr_ring_ll_produce(>ring, skb);
> +}
> +
[...]
>
> +static inline struct sk_buff *skb_array_ll_consume(struct skb_array_ll *a)
> +{
>
produce(struct skb_array_ll *a, struct
> sk_buff *skb)
> +{
> + return __ptr_ring_ll_produce(>ring, skb);
> +}
> +
[...]
>
> +static inline struct sk_buff *skb_array_ll_consume(struct skb_array_ll *a)
> +{
> + return __ptr_ring_ll_consume(>ring);
> +}
> +
Note
Trivial spelling fixes for Kconfig help text of config HWLAT_TRACER.
Fixes: e7c15cd8a113 ("tracing: Added hardware latency tracer")
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
kernel/trace/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
Trivial spelling fixes for Kconfig help text of config HWLAT_TRACER.
Fixes: e7c15cd8a113 ("tracing: Added hardware latency tracer")
Signed-off-by: Jesper Dangaard Brouer
---
kernel/trace/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace
doing this work Alex, thanks! And I do
think it fits into my page pool plans. Thanks!
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
do
think it fits into my page pool plans. Thanks!
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
ormance:
https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test01.c
Acked-by: Jesper Dangaard Brouer <bro...@redhat.com>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> mm/slub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test01.c
Acked-by: Jesper Dangaard Brouer
> Signed-off-by: Arnd Bergmann
> ---
> mm/slub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 2b
ng this up! It is a very important fix, as least
for networking.
This is your git tree, right:
https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/
Doesn't look like you pushed it yet, or do I need to look at a specific
branch?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, P
tant fix, as least
for networking.
This is your git tree, right:
https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/
Doesn't look like you pushed it yet, or do I need to look at a specific
branch?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
n fault" for your
script...
The mentioned commit: d0ecd894e3d5f768a84 removes a call point to
__slab_free() and instead call slab_free(). It does not make sense to
my, why this results in a linker error on this ARCH=microblaze.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
The mentioned commit: d0ecd894e3d5f768a84 removes a call point to
__slab_free() and instead call slab_free(). It does not make sense to
my, why this results in a linker error on this ARCH=microblaze.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
On Thu, 1 Sep 2016 17:28:02 +0200
Peter Zijlstra <pet...@infradead.org> wrote:
> On Thu, Sep 01, 2016 at 03:30:42PM +0200, Jesper Dangaard Brouer wrote:
> > Still... enabled!
> > Hmmm.. more idea how to disable this???
>
> I think you ought to be able to assign
On Thu, 1 Sep 2016 17:28:02 +0200
Peter Zijlstra wrote:
> On Thu, Sep 01, 2016 at 03:30:42PM +0200, Jesper Dangaard Brouer wrote:
> > Still... enabled!
> > Hmmm.. more idea how to disable this???
>
> I think you ought to be able to assign yourself to the root cgr
On Thu, 1 Sep 2016 14:48:39 +0200
Peter Zijlstra <pet...@infradead.org> wrote:
> On Thu, Sep 01, 2016 at 02:38:59PM +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 1 Sep 2016 14:29:25 +0200
> > Jesper Dangaard Brouer <bro...@redhat.com> wrote:
> >
> &
On Thu, 1 Sep 2016 14:48:39 +0200
Peter Zijlstra wrote:
> On Thu, Sep 01, 2016 at 02:38:59PM +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 1 Sep 2016 14:29:25 +0200
> > Jesper Dangaard Brouer wrote:
> >
> > > On Thu, 1 Sep 2016 13:53:56 +02
On Thu, 1 Sep 2016 14:29:25 +0200
Jesper Dangaard Brouer <bro...@redhat.com> wrote:
> On Thu, 1 Sep 2016 13:53:56 +0200
> Peter Zijlstra <pet...@infradead.org> wrote:
>
> > On Thu, Sep 01, 2016 at 01:02:31PM +0200, Jesper Dangaard Brouer wrote:
> > >
On Thu, 1 Sep 2016 14:29:25 +0200
Jesper Dangaard Brouer wrote:
> On Thu, 1 Sep 2016 13:53:56 +0200
> Peter Zijlstra wrote:
>
> > On Thu, Sep 01, 2016 at 01:02:31PM +0200, Jesper Dangaard Brouer wrote:
> > >PID S %CPU TIME+ COMMAND
> > >
On Thu, 1 Sep 2016 13:53:56 +0200
Peter Zijlstra <pet...@infradead.org> wrote:
> On Thu, Sep 01, 2016 at 01:02:31PM +0200, Jesper Dangaard Brouer wrote:
> >PID S %CPU TIME+ COMMAND
> > 3 R 50.0 29:02.23 ksoftirqd/0
> > 10881 R 10.7 1:01.61 u
On Thu, 1 Sep 2016 13:53:56 +0200
Peter Zijlstra wrote:
> On Thu, Sep 01, 2016 at 01:02:31PM +0200, Jesper Dangaard Brouer wrote:
> >PID S %CPU TIME+ COMMAND
> > 3 R 50.0 29:02.23 ksoftirqd/0
> > 10881 R 10.7 1:01.61 udp_sink
> > 10837
On Wed, 31 Aug 2016 23:51:16 +0200
Jesper Dangaard Brouer <jbro...@redhat.com> wrote:
> On Wed, 31 Aug 2016 13:42:30 -0700
> Eric Dumazet <eric.duma...@gmail.com> wrote:
>
> > On Wed, 2016-08-31 at 21:40 +0200, Jesper Dangaard Brouer wrote:
> >
> > &g
On Wed, 31 Aug 2016 23:51:16 +0200
Jesper Dangaard Brouer wrote:
> On Wed, 31 Aug 2016 13:42:30 -0700
> Eric Dumazet wrote:
>
> > On Wed, 2016-08-31 at 21:40 +0200, Jesper Dangaard Brouer wrote:
> >
> > > I can confirm the improvement of approx 900Kpps (no
ax queue of 47MBytes, and worse an average standing queue of
25Mbytes, which is really bad for the latency seen by the
application. And having this much outstanding memory is also bad for
CPU cache size effects, and stressing the memory allocator.
I'm actually using this huge queue "misco
worse an average standing queue of
25Mbytes, which is really bad for the latency seen by the
application. And having this much outstanding memory is also bad for
CPU cache size effects, and stressing the memory allocator.
I'm actually using this huge queue "misconfig" to stress the page
allo
On Wed, 31 Aug 2016 13:42:30 -0700
Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Wed, 2016-08-31 at 21:40 +0200, Jesper Dangaard Brouer wrote:
>
> > I can confirm the improvement of approx 900Kpps (no wonder people have
> > been complaining about DoS
On Wed, 31 Aug 2016 13:42:30 -0700
Eric Dumazet wrote:
> On Wed, 2016-08-31 at 21:40 +0200, Jesper Dangaard Brouer wrote:
>
> > I can confirm the improvement of approx 900Kpps (no wonder people have
> > been complaining about DoS against UDP/DNS servers).
> >
>
:21.53 netserver
10784 24.3 0:21.53 netserver
10785 24.3 0:21.52 netserver
10786 24.3 0:21.50 netserver
3 2.7 3:12.18 ksoftirqd/0
> Reported-by: Paolo Abeni <pab...@redhat.com>
> Reported-by: Hannes Frederic Sowa <han...@stressinduktion.org>
> Signed-off-by: Eri
24.3 0:21.52 netserver
10786 24.3 0:21.50 netserver
3 2.7 3:12.18 ksoftirqd/0
> Reported-by: Paolo Abeni
> Reported-by: Hannes Frederic Sowa
> Signed-off-by: Eric Dumazet
> Cc: David Miller Cc: Jesper Dangaard Brouer
> Cc: Peter Zijlstra
> Cc: Rik van Riel
>
On Tue, 8 Mar 2016 10:50:56 +0100
Jesper Dangaard Brouer <jbro...@redhat.com> wrote:
> On Mon, 7 Mar 2016 12:54:13 -0500
> Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote:
>
> > On Mon, Mar 7, 2016 at 10:36 AM, Jesper Dangaard Brouer
> > <jbro...@
On Tue, 8 Mar 2016 10:50:56 +0100
Jesper Dangaard Brouer wrote:
> On Mon, 7 Mar 2016 12:54:13 -0500
> Willem de Bruijn wrote:
>
> > On Mon, Mar 7, 2016 at 10:36 AM, Jesper Dangaard Brouer
> > wrote:
> > > Hi Google,
> > >
> > > While playing w
On Mon, 13 Jun 2016 23:54:50 +0300
"Michael S. Tsirkin" <m...@redhat.com> wrote:
> Update skb_array after ptr_ring API changes.
>
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Acked-by: Jesper Dangaard Brouer <bro...@redhat.com>
Tested-by: Jesp
On Mon, 13 Jun 2016 23:54:50 +0300
"Michael S. Tsirkin" wrote:
> Update skb_array after ptr_ring API changes.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Jesper Dangaard Brouer
Tested-by: Jesper Dangaard Brouer
Also did resize unit test:
https://github.com/net
ains destructor callback such that
> all pointers in queue can be cleaned up.
>
> This changes some APIs but we don't have any users yet,
> so it won't break bisect.
>
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Acked-by: Jesper Dangaard Brouer <bro...@redhat
lback such that
> all pointers in queue can be cleaned up.
>
> This changes some APIs but we don't have any users yet,
> so it won't break bisect.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Jesper Dangaard Brouer
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Pri
301 - 400 of 564 matches
Mail list logo
