> That would be one option indeed (probably useful in any case to make the API
> more robust). Another one is to just not use GFP_ATOMIC in cpumap. Looking at
> it, update can neither be called out of a BPF prog since prevented by verifier
> nor under RCU reader side when updating this type of map from syscall path.
> Jesper, any concrete reason we still need GFP_ATOMIC here?
Allocations in cpumap (related to ptr_ring) should only be possible to
be initiated through userspace via bpf-syscall. Thus, there isn't any
reason for GFP_ATOMIC here.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
t it's a MM-decision (and
sometimes you should not listen to "fanatics" ;-))
void kvfree(const void *addr)
{
if (is_vmalloc_addr(addr))
vfree(addr);
else
kfree(addr);
}
EXPORT_SYMBOL(kvfree);
--
Best regards,
Jesper Dangaard Brouer
MSc.
"fanatics" ;-))
void kvfree(const void *addr)
{
if (is_vmalloc_addr(addr))
vfree(addr);
else
kfree(addr);
}
EXPORT_SYMBOL(kvfree);
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://ww
sed at the moment.
Next time you submit read[1] and [2], especially howto indicate which
tree (bpf vs. bpf-next) the patch is against, as this helps the
workflow of the maintainers.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Documentation/bpf/bpf_devel_QA.txt
[2
.
Next time you submit read[1] and [2], especially howto indicate which
tree (bpf vs. bpf-next) the patch is against, as this helps the
workflow of the maintainers.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Documentation/bpf/bpf_devel_QA.txt
[2] Documentation/networking
("bpf tools: Introduce 'bpf' library and add bpf feature
check")
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
tools/lib/bpf/Makefile | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bp
("bpf tools: Introduce 'bpf' library and add bpf feature
check")
Signed-off-by: Jesper Dangaard Brouer
---
tools/lib/bpf/Makefile | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 54370654c708..8e
This patchset contains some small improvements and cleanup for
the Makefile in tools/lib/bpf/.
It worries me that the libbpf.so shared library is not versioned, but
it not addressed in this patchset.
---
Jesper Dangaard Brouer (3):
libbpf: install the header file libbpf.h
libbpf
This patchset contains some small improvements and cleanup for
the Makefile in tools/lib/bpf/.
It worries me that the libbpf.so shared library is not versioned, but
it not addressed in this patchset.
---
Jesper Dangaard Brouer (3):
libbpf: install the header file libbpf.h
libbpf
his change, the header files are install as executables files (755).
Fixes: eb54e522a000 ("bpf: install libbpf headers on 'make install'")
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
tools/lib/bpf/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
It seems like an oversight not to install the header file for libbpf,
given the libbpf.so + libbpf.a files are installed.
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
tools/lib/bpf/Makefile |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/l
his change, the header files are install as executables files (755).
Fixes: eb54e522a000 ("bpf: install libbpf headers on 'make install'")
Signed-off-by: Jesper Dangaard Brouer
---
tools/lib/bpf/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/Make
It seems like an oversight not to install the header file for libbpf,
given the libbpf.so + libbpf.a files are installed.
Signed-off-by: Jesper Dangaard Brouer
---
tools/lib/bpf/Makefile |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib
flare.com/how-to-receive-a-million-packets/
p.s. Regarding quote[1] point "1.", after Paolo Abeni optimized the UDP
code, that statement is no longer true. It now (significantly) faster to
run/pin your UDP application to another CPU than the RX-CPU.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
ts/
p.s. Regarding quote[1] point "1.", after Paolo Abeni optimized the UDP
code, that statement is no longer true. It now (significantly) faster to
run/pin your UDP application to another CPU than the RX-CPU.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
y: Guenter Roeck <li...@roeck-us.net>
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
include/linux/netdevice.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 440b000f07f4..b308793c64ce 100644
--- a/include
ed-by: Guenter Roeck
Signed-off-by: Jesper Dangaard Brouer
---
include/linux/netdevice.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 440b000f07f4..b308793c64ce 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
ev.c:7633:29: error:
> 'struct net_device' has no member named 'num_rx_queues'
>
> [ and so on ]
Hi Guenter,
This is caused by CONFIG_SYSFS is not set in your config. I'm
preparing a patch... can I ask you to test it, as I have a hard time
disabling on my X86_64 system.
--
Best
gt; 'struct net_device' has no member named 'num_rx_queues'
>
> [ and so on ]
Hi Guenter,
This is caused by CONFIG_SYSFS is not set in your config. I'm
preparing a patch... can I ask you to test it, as I have a hard time
disabling on my X86_64 system.
--
Best regards,
Jesper Dangaar
e issue...
Their system have non-preempt kernel, should they use PREEMPT?
LibreELEC:~ # uname -a
Linux LibreELEC 4.14.10 #1 SMP Tue Jan 9 17:35:03 GMT 2018 armv7l GNU/Linux
[2]
https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=76999#post76999
--
EMPT?
LibreELEC:~ # uname -a
Linux LibreELEC 4.14.10 #1 SMP Tue Jan 9 17:35:03 GMT 2018 armv7l GNU/Linux
[2]
https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=76999#post76999
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel
On Mon, 8 Jan 2018 22:44:27 +0100
Peter Zijlstra <pet...@infradead.org> wrote:
> On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote:
> > I did expected the issue to get worse, when you load the Pi with
> > network traffic, as now the softirq time-bud
On Mon, 8 Jan 2018 22:44:27 +0100
Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote:
> > I did expected the issue to get worse, when you load the Pi with
> > network traffic, as now the softirq time-budget have to be shared
> &g
rtunately there's no usbmon or tshark on libreelec so I can't
> provide further logs.
Do you have perf or trace-cmd on the box? Maybe we could come up with
some kernel functions to trace, to measure/show the latency spikes?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Ker
tshark on libreelec so I can't
> provide further logs.
Do you have perf or trace-cmd on the box? Maybe we could come up with
some kernel functions to trace, to measure/show the latency spikes?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
g:80/wiki/index.php/Lab_Setup
[4]
http://web.archive.org/web/20150328234459/http://www.iptv-analyzer.org:80/wiki/index.php/Multicast_Signal_on_Linux
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
p
[4]
http://web.archive.org/web/20150328234459/http://www.iptv-analyzer.org:80/wiki/index.php/Multicast_Signal_on_Linux
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
n admin choice before).
> For example, we didn't have any reports about this issue affecting cameras,
> Most cameras use ISOC nowadays, but some only provide bulk transfers.
> We usually try to use the minimum number of buffers possible, as
> increasing latency on cameras can be very annoying, specially on
> videoconference applications.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
want, so as the also commit mentions, the admin can now
more easily tune process scheduling parameters if needed, to adjust for
such use-cases (it was not really an admin choice before).
> For example, we didn't have any reports about this issue affecting cameras,
> Most camer
xdp_redirect_map is
> doing redirection from ixgbe to TAP.
IMHO a performance measurement without something to compare against is
useless. What was the performance before?
> Cc: Jesper Dangaard Brouer <bro...@redhat.com>
> Signed-off-by: Jason Wang
doing redirection from ixgbe to TAP.
IMHO a performance measurement without something to compare against is
useless. What was the performance before?
> Cc: Jesper Dangaard Brouer
> Signed-off-by: Jason Wang
> ---
> drivers/net/tun.c | 205
>
is similar to quilt, just git based
itself.
I guess most people on this list use 'git rebase --interactive' when
updating their patchsets (?)
[1] http://procode.org/stgit/doc/tutorial.html
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
based
itself.
I guess most people on this list use 'git rebase --interactive' when
updating their patchsets (?)
[1] http://procode.org/stgit/doc/tutorial.html
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
On Tue, 19 Dec 2017 13:20:43 -0800 Rao Shoaib <rao.sho...@oracle.com> wrote:
> On 12/19/2017 12:41 PM, Jesper Dangaard Brouer wrote:
> > On Tue, 19 Dec 2017 09:52:27 -0800 rao.sho...@oracle.com wrote:
> >
> >> +/* Main RCU function that is called to free RCU s
On Tue, 19 Dec 2017 13:20:43 -0800 Rao Shoaib wrote:
> On 12/19/2017 12:41 PM, Jesper Dangaard Brouer wrote:
> > On Tue, 19 Dec 2017 09:52:27 -0800 rao.sho...@oracle.com wrote:
> >
> >> +/* Main RCU function that is called to free RCU structures */
> >> +
On Tue, 19 Dec 2017 16:20:51 -0800
"Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:
> On Tue, Dec 19, 2017 at 02:12:06PM -0800, Matthew Wilcox wrote:
> > On Tue, Dec 19, 2017 at 09:41:58PM +0100, Jesper Dangaard Brouer wrote:
> > > If I had to im
On Tue, 19 Dec 2017 16:20:51 -0800
"Paul E. McKenney" wrote:
> On Tue, Dec 19, 2017 at 02:12:06PM -0800, Matthew Wilcox wrote:
> > On Tue, Dec 19, 2017 at 09:41:58PM +0100, Jesper Dangaard Brouer wrote:
> > > If I had to implement this: I would c
rbfc->rbfc_data[rbfc->rbfc_entries++] = ptr;
> + if (rbfc->rbfc_entries == RCU_MAX_ACCUMULATE_SIZE) {
> +
> + WRITE_ONCE(rbf->rbf_container, NULL);
> + spin_unlock_bh(>rbf_lock);
> + call_rcu(>rbfc_rcu, __rcu_bulk_free_impl);
> + retu
rbfc->rbfc_data[rbfc->rbfc_entries++] = ptr;
> + if (rbfc->rbfc_entries == RCU_MAX_ACCUMULATE_SIZE) {
> +
> + WRITE_ONCE(rbf->rbf_container, NULL);
> + spin_unlock_bh(>rbf_lock);
> + call_rcu(>rbfc_rcu, __rcu_bulk_free_impl);
> + retu
in cleanups (which should be avoided, and
instead moved to another patch).
> @@ -1483,6 +1486,197 @@ void kzfree(const void *p)
[...]
> +
> +/* processes list of rcu structures
> + * used when conatiner can not be allocated
> + */
Spelling.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
in cleanups (which should be avoided, and
instead moved to another patch).
> @@ -1483,6 +1486,197 @@ void kzfree(const void *p)
[...]
> +
> +/* processes list of rcu structures
> + * used when conatiner can not be allocated
> + */
Spelling.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
loc_bulk(struct kmem_cache *s, gfp_t
> flags, size_t size,
> return i;
> error:
> local_irq_enable();
> + free_delayed(_free);
> slab_post_alloc_hook(s, flags, i, p);
> __kmem_cache_free_bulk(s, i, p);
> return 0;
I've not seen free_delayed() before... a
return i;
> error:
> local_irq_enable();
> + free_delayed(_free);
> slab_post_alloc_hook(s, flags, i, p);
> __kmem_cache_free_bulk(s, i, p);
> return 0;
I've not seen free_delayed() before... and my cscope cannot find it...
--
Best regards,
Jesper
nclude
> #include
> +#include
> #include "q_struct.h"
>
> #define MAX_QUEUE_SET128
> @@ -92,6 +93,9 @@
> #define RCV_FRAG_LEN (SKB_DATA_ALIGN(DMA_BUFFER_LEN + NET_SKB_PAD) + \
>SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
>
> +#define RCV_BUF_HEADROOM 128 /* To store dma address for XDP redirect */
> +#define XDP_HEADROOM (XDP_PACKET_HEADROOM + RCV_BUF_HEADROOM)
> +
> #define MAX_CQES_FOR_TX ((SND_QUEUE_LEN /
> MIN_SQ_DESC_PER_PKT_XMIT) * \
>MAX_CQE_PER_PKT_XMIT)
>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
queues.h
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
> #include "q_struct.h"
>
> #define MAX_QUEUE_SET 128
> @@ -92,6 +93,9 @@
> #define RCV_FRAG_LEN (SKB_DA
ace/events/xdp.h
> > +++ b/include/trace/events/xdp.h
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> Isn't it just enough to add:
> struct bpf_map;
> before the first prototype instead of pulling in the entir
lude/trace/events/xdp.h
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> Isn't it just enough to add:
> struct bpf_map;
> before the first prototype instead of pulling in the entire header?
Nope, because we deref map->id.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
#include
> #include
> +#include
>
> #define __XDP_ACT_MAP(FN)\
> FN(ABORTED) \
Strange that I'm not see this compile issue, and kbuild-bot also didn't
report it, but the patch looks okay to me... I guess I introduced the
issue in below "fixes"
\
Strange that I'm not see this compile issue, and kbuild-bot also didn't
report it, but the patch looks okay to me... I guess I introduced the
issue in below "fixes" commit. Can the person applying this include
the fixes line?
Fixes: 8d3b778ff544 ("xdp: tracepoint xdp_re
've not had time to proper test (and review) this V4 patch, but I
guess I'll have to do so when I get home from Seoul...
I especially want to measure the effect of using bpf_redirect_map().
To Christina: what performance improvement did you see on your
board/arch when switching from bpf_redir
ally want to measure the effect of using bpf_redirect_map().
To Christina: what performance improvement did you see on your
board/arch when switching from bpf_redirect() to bpf_redirect_map()?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
value = bpf_map_lookup_elem(, );
> + if (value)
> + *value += 1;
> + return bpf_redirect(forward_to, 0);
Notice that using bpf_redirect() is slow, while using bpf_redirect_map()
is fast. Using bpf_redirect_map() requires a litt
e += 1;
> + return bpf_redirect(forward_to, 0);
Notice that using bpf_redirect() is slow, while using bpf_redirect_map()
is fast. Using bpf_redirect_map() requires a little more book keeping,
but the performance gain is worth it.
Raw benchmarks on my system show:
* bpf_redirect() max at 7Mpps
* bpf_redirect_map() at 13Mpps
Trying out your program on my systems showed it jumps between 5.6Mpps
to 7Mpps. And it seems to be correlated with matching direct_entry.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
else {
> + ipproto = 0;
> + }
The nesting in this function is getting annoying to read.
Kernel code often use "early return" style coding to solve this.
A quick search turns up this guide, look at section "Early return"
https://en.wikibooks.org/wiki/Computer_Programming/Coding_Style/Minimize_nesting
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
gt; + }
The nesting in this function is getting annoying to read.
Kernel code often use "early return" style coding to solve this.
A quick search turns up this guide, look at section "Early return"
https://en.wikibooks.org/wiki/Computer_Programming/Coding_Style/Minimize_nesting
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
On Tue, 10 Oct 2017 15:12:31 +0200
Jesper Dangaard Brouer <bro...@redhat.com> wrote:
> I'll try to test/benchmark your program...
In my initial testing, I cannot get this to work...
You do seem to XDP_REDIRECT out the right interface, but you have an
error with setting the correct MA
On Tue, 10 Oct 2017 15:12:31 +0200
Jesper Dangaard Brouer wrote:
> I'll try to test/benchmark your program...
In my initial testing, I cannot get this to work...
You do seem to XDP_REDIRECT out the right interface, but you have an
error with setting the correct MAC address.
--
Best rega
able array map.
>
> Usage: as ./xdp3 -S (-S for
^
The executable name also changed.
> generic xdp implementation ifindex- the index of the interface to which
> the xdp program has to be attached.) in 4.14-rc3 kernel.
>
> Changes from v1 t
xdp3 -S (-S for
^
The executable name also changed.
> generic xdp implementation ifindex- the index of the interface to which
> the xdp program has to be attached.) in 4.14-rc3 kernel.
>
> Changes from v1 to v2
> -
>
>
options like [1] and [2].
[1]
http://lkml.kernel.org/r/150711864538.9499.11712573036995600273.stgit@firesoul
[2]
https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_redirect_cpu_user.c
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
1864538.9499.11712573036995600273.stgit@firesoul
[2]
https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_redirect_cpu_user.c
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
t by Dave Hansen).
> >
>
> For the series;
>
> Acked-by: Mel Gorman <mgor...@techsingularity.net>
>
I'm very happy to see these issues being worked on, from our MM-summit
interactions. I would like to provide/have a:
Reported-by: Jesper Dangaard Brouer <bro...
gt;
> For the series;
>
> Acked-by: Mel Gorman
>
I'm very happy to see these issues being worked on, from our MM-summit
interactions. I would like to provide/have a:
Reported-by: Jesper Dangaard Brouer
As I'm not sure an acked-by from me have any value/merit here ;-)
--
Best regards,
Commit-ID: d0618410eced4eb092295fad10312a4545fcdfaf
Gitweb: http://git.kernel.org/tip/d0618410eced4eb092295fad10312a4545fcdfaf
Author: Jesper Dangaard Brouer <bro...@redhat.com>
AuthorDate: Tue, 22 Aug 2017 19:22:43 +0200
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate:
Commit-ID: d0618410eced4eb092295fad10312a4545fcdfaf
Gitweb: http://git.kernel.org/tip/d0618410eced4eb092295fad10312a4545fcdfaf
Author: Jesper Dangaard Brouer
AuthorDate: Tue, 22 Aug 2017 19:22:43 +0200
Committer: Ingo Molnar
CommitDate: Fri, 25 Aug 2017 11:04:18 +0200
tracing, perf
was chosen (by the compiler) as the most likely
event/branch. This small adjustment makes the compiler (gcc version
7.1.1 20170622 (Red Hat 7.1.1-3)) put in_nmi() as an unlikely branch.
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
kernel/events/internal.h |2 +-
1 file c
was chosen (by the compiler) as the most likely
event/branch. This small adjustment makes the compiler (gcc version
7.1.1 20170622 (Red Hat 7.1.1-3)) put in_nmi() as an unlikely branch.
Signed-off-by: Jesper Dangaard Brouer
---
kernel/events/internal.h |2 +-
1 file changed, 1 insertion(+), 1
On Tue, 22 Aug 2017 19:00:39 +0200
Jesper Dangaard Brouer <bro...@redhat.com> wrote:
> On Tue, 22 Aug 2017 17:20:25 +0200
> Peter Zijlstra <pet...@infradead.org> wrote:
>
> > On Tue, Aug 22, 2017 at 05:14:10PM +0200, Peter Zijlstra wrote:
> > > On Tue, Aug
On Tue, 22 Aug 2017 19:00:39 +0200
Jesper Dangaard Brouer wrote:
> On Tue, 22 Aug 2017 17:20:25 +0200
> Peter Zijlstra wrote:
>
> > On Tue, Aug 22, 2017 at 05:14:10PM +0200, Peter Zijlstra wrote:
> > > On Tue, Aug 22, 2017 at 04:40:24PM +0200, Jesp
On Tue, 22 Aug 2017 17:20:25 +0200
Peter Zijlstra <pet...@infradead.org> wrote:
> On Tue, Aug 22, 2017 at 05:14:10PM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 22, 2017 at 04:40:24PM +0200, Jesper Dangaard Brouer wrote:
> > > In an XDP redirect applications using tra
On Tue, 22 Aug 2017 17:20:25 +0200
Peter Zijlstra wrote:
> On Tue, Aug 22, 2017 at 05:14:10PM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 22, 2017 at 04:40:24PM +0200, Jesper Dangaard Brouer wrote:
> > > In an XDP redirect applications using tracepoint xdp:xdp_redirect to
was chosen (by the compiler) as the most likely
event/branch. This small adjustment makes the compiler (gcc version
7.1.1 20170622 (Red Hat 7.1.1-3)) put in_nmi() as an unlikely branch.
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
---
kernel/events/internal.h |8
was chosen (by the compiler) as the most likely
event/branch. This small adjustment makes the compiler (gcc version
7.1.1 20170622 (Red Hat 7.1.1-3)) put in_nmi() as an unlikely branch.
Signed-off-by: Jesper Dangaard Brouer
---
kernel/events/internal.h |8
1 file changed, 4 insertions
e zone_statistics
>
> Kemi Wang (2):
> mm: Change the call sites of numa statistics items
> mm: Update NUMA counter threshold size
>
> drivers/base/node.c| 22 ---
> include/linux/mmzone.h | 25 +---
> include/linux/vmstat.h | 33 ++
> mm/page_alloc.c
mi Wang (2):
> mm: Change the call sites of numa statistics items
> mm: Update NUMA counter threshold size
>
> drivers/base/node.c| 22 ---
> include/linux/mmzone.h | 25 +---
> include/linux/vmstat.h | 33 ++
> mm/page_alloc.c| 10 +--
>
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>
Acked-by: Steven Rostedt <rost...@goodmis.org>
---
Resend of: https://patchwork.ke
Trivial spelling fixes for Kconfig help text of config HWLAT_TRACER.
Fixes: e7c15cd8a113 ("tracing: Added hardware latency tracer")
Signed-off-by: Jesper Dangaard Brouer
Acked-by: Steven Rostedt
---
Resend of: https://patchwork.kernel.org/patch/9405223/
kernel/trace/Kconfig |
On Tue, 9 May 2017 16:33:14 +0300
"Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Sat, Apr 08, 2017 at 02:14:08PM +0200, Jesper Dangaard Brouer wrote:
> > On Fri, 7 Apr 2017 08:49:57 +0300
> > "Michael S. Tsirkin" <m...@redhat.com> wrote:
&
On Tue, 9 May 2017 16:33:14 +0300
"Michael S. Tsirkin" wrote:
> On Sat, Apr 08, 2017 at 02:14:08PM +0200, Jesper Dangaard Brouer wrote:
> > On Fri, 7 Apr 2017 08:49:57 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > A known weakness
the strict IRQ time in a separate counter and
> use it to report the IRQ time.
>
> Reported-and-tested-by: Jesper Dangaard Brouer <bro...@redhat.com>
Acked-by: Jesper Dangaard Brouer <bro...@redhat.com>
Confirming I have tested patch before Frederic posted it, and have been
me in a separate counter and
> use it to report the IRQ time.
>
> Reported-and-tested-by: Jesper Dangaard Brouer
Acked-by: Jesper Dangaard Brouer
Confirming I have tested patch before Frederic posted it, and have been
running with this applied on my net-next testlab kernels sin
t; column, while on v4.10 "top" also blames
"ksoftirqd/N", plus "ps" reported cputime (0:00) seems wrong for ksoftirqd.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
t; column, while on v4.10 "top" also blames
"ksoftirqd/N", plus "ps" reported cputime (0:00) seems wrong for ksoftirqd.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
echsingularity.net>
> Reported-by: Tariq Toukan <ttoukan.li...@gmail.com>
Acked-by: Jesper Dangaard Brouer <bro...@redhat.com>
> ---
> mm/page_alloc.c | 43 ---
> 1 file changed, 20 insertions(+), 23 deletions(-)
>
>
riq to re-run these benchmarks on some
hardware with enough memory bandwidth for 100Gbit/s throughput.
> As this is a regression, I wish to revert to noirq allocator for now and
> go back to the drawing board.
>
> Signed-off-by: Mel Gorman
> Reported-by: Tariq
ee. If further concerns are highlighted by this patch,
> > the result wiill be to revert 374ad05ab64d and try again at a later date
> > to offset the irq enable/disable overhead.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
> never access the page allocator, thus it should be sufficient to only test
> > for !in_irq().
> >
> > One concern with this change is adding a BH (enable) scheduling point at
> > both PCP alloc and free. If further concerns are highlighted by this patch,
> >
some more testing with 100G NIC (he
also participated in the Montreal conf, so he is likely in transit too).
On Mon, 10 Apr 2017 16:08:21 +0100
Mel Gorman <mgor...@techsingularity.net> wrote:
> From: Jesper Dangaard Brouer <bro...@redhat.com>
>
> IRQ context were excluded fr
some more testing with 100G NIC (he
also participated in the Montreal conf, so he is likely in transit too).
On Mon, 10 Apr 2017 16:08:21 +0100
Mel Gorman wrote:
> From: Jesper Dangaard Brouer
>
> IRQ context were excluded from using the Per-Cpu-Pages (PCP) lists caching
> of o
ides the first one until we write out all entries.
> + */
> + while (likely(head >= r->consumer_tail))
> + r->queue[head--] = NULL;
> + r->consumer_tail = r->consumer_head;
> + }
> + if (unlikely(r->consume
ries.
> + */
> + while (likely(head >= r->consumer_tail))
> + r->queue[head--] = NULL;
> + r->consumer_tail = r->consumer_head;
> + }
> + if (unlikely(r->consumer_head >= r->size)) {
> +
On Thu, 30 Mar 2017 14:04:36 +0100
Mel Gorman <mgor...@techsingularity.net> wrote:
> On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote:
> > > Regardless or using in_irq() (or in combi with in_nmi()) I get the
> > > following warning below:
> &g
On Thu, 30 Mar 2017 14:04:36 +0100
Mel Gorman wrote:
> On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote:
> > > Regardless or using in_irq() (or in combi with in_nmi()) I get the
> > > following warning below:
> > >
> >
On Thu, 30 Mar 2017 09:35:02 +0200
Peter Zijlstra <pet...@infradead.org> wrote:
> On Thu, Mar 30, 2017 at 09:12:23AM +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 30 Mar 2017 08:49:58 +0200
> > Peter Zijlstra <pet...@infradead.org> wrote:
> >
> > >
On Thu, 30 Mar 2017 09:35:02 +0200
Peter Zijlstra wrote:
> On Thu, Mar 30, 2017 at 09:12:23AM +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 30 Mar 2017 08:49:58 +0200
> > Peter Zijlstra wrote:
> >
> > > On Wed, Mar 29, 2017 at 09:44:41PM +0200
On Thu, 30 Mar 2017 08:49:58 +0200
Peter Zijlstra <pet...@infradead.org> wrote:
> On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote:
> > @@ -2481,7 +2481,11 @@ void free_hot_cold_page(struct page *page, bool cold)
> > unsigned long pfn = page_to_p
On Thu, 30 Mar 2017 08:49:58 +0200
Peter Zijlstra wrote:
> On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote:
> > @@ -2481,7 +2481,11 @@ void free_hot_cold_page(struct page *page, bool cold)
> > unsigned long pfn = page_to_pfn(page);
> >
On Wed, 29 Mar 2017 21:11:44 +0200
Jesper Dangaard Brouer <bro...@redhat.com> wrote:
> 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,
On Wed, 29 Mar 2017 21:11:44 +0200
Jesper Dangaard Brouer wrote:
> 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
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
&
201 - 300 of 563 matches
Mail list logo
