Hi,
I've been asked to repost LLVM eBPF backend and examples in C, so here they are.
LLVM backend is 99% the same as it was in Feb. Not resending it to the list,
since I only fixed minor things there. See it in my tree.
ex1 - is the same example I showed in Feb, but now it works through BPF sysca
simple .o parser and loader using BPF syscall.
.o is a standard ELF generated by LLVM backend
/* parses elf file compiled by llvm .c->.o
* creates maps and stores FD into map_fd array
* loads eBPF programs
* returns zero on success
*/
int load_bpf_file(char *path);
Signed-off-by: Alexei Staro
semantically this example is the same as dropmon.c which has eBPF in assembler.
In this example both eBPF and user space are in C:
ex2_kern.c - C code that will compile into eBPF and will
be attached to kfree_skb event
ex2_user.c - corresponding user space part that iterates the map
populated
ex1_kern.c - C program which will be compiled into eBPF
to filter netif_receive_skb events on skb->dev->name == "lo"
ex1_user.c - corresponding user space component that
forever reads /sys/.../trace_pipe
Usage:
$ sudo ex1 ex1_kern.o
should see:
writing bpf-4 -> /sys/kernel/debug/tracing/events/n
On 07/21/2014 11:45 AM, Randy Dunlap wrote:
On 07/21/2014 08:24 AM, Waiman Long wrote:
This patch adds a new document file on how to use the spinning futexes.
Signed-off-by: Waiman Long
---
Documentation/spinning-futex.txt | 109 ++
1 files changed, 109 i
On Mon, 2014-07-21 at 21:34 -0400, Steven Rostedt wrote:
> On Tue, 22 Jul 2014 03:01:00 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > On Mon, 21 Jul 2014, Darren Hart wrote:
> > > On 7/21/14, 14:47, "Thomas Gleixner" wrote:
> > >
> > > >On Mon, 21 Jul 2014, Andy Lutomirski wrote:
> > > >> On Mon,
On Mon, 2014-07-21 at 21:34 -0400, Steven Rostedt wrote:
> I was telling Robert that if futexes get optimistic spinning, he should
> reconsider their use of userspace spinlocks in favor of this, because
> I'm pretty sure that they will see a great improvement.
My (dated) experience with pgsql say
On Tue, 22 Jul 2014 03:01:00 +0200 (CEST)
Thomas Gleixner wrote:
> On Mon, 21 Jul 2014, Darren Hart wrote:
> > On 7/21/14, 14:47, "Thomas Gleixner" wrote:
> >
> > >On Mon, 21 Jul 2014, Andy Lutomirski wrote:
> > >> On Mon, Jul 21, 2014 at 2:27 PM, Peter Zijlstra
> > >>wrote:
> > >> > All this
On Mon, 21 Jul 2014, Darren Hart wrote:
> On 7/21/14, 14:47, "Thomas Gleixner" wrote:
>
> >On Mon, 21 Jul 2014, Andy Lutomirski wrote:
> >> On Mon, Jul 21, 2014 at 2:27 PM, Peter Zijlstra
> >>wrote:
> >> > All this is predicated on the fact that syscalls are 'expensive'.
> >> > Weren't syscalls
On Mon, 2014-07-21 at 14:31 -0700, Andy Lutomirski wrote:
> On Mon, Jul 21, 2014 at 2:27 PM, Peter Zijlstra wrote:
> > All this is predicated on the fact that syscalls are 'expensive'.
> > Weren't syscalls only 100s of cycles? All this bitmap mucking is far
> > more expensive due to cacheline miss
On 7/21/14, 14:47, "Thomas Gleixner" wrote:
>On Mon, 21 Jul 2014, Andy Lutomirski wrote:
>> On Mon, Jul 21, 2014 at 2:27 PM, Peter Zijlstra
>>wrote:
>> > All this is predicated on the fact that syscalls are 'expensive'.
>> > Weren't syscalls only 100s of cycles? All this bitmap mucking is far
>>
On Mon, Jul 21, 2014 at 10:21:26PM +0200, Till Smejkal wrote:
> Hi,
>
> On Fri, 18 Jul 2014, Theodore Ts'o wrote:
> [...]
> > If the GRND_RANDOM bit is not set, then the /dev/urandom pool
> > will be used. Unlike using read(2) to fetch data from
> > /dev/urandom, if the urandom pool h
On Mon, Jul 21, 2014 at 3:11 PM, Aditya Kali wrote:
> On Fri, Jul 18, 2014 at 11:57 AM, Andy Lutomirski wrote:
>> On Fri, Jul 18, 2014 at 11:51 AM, Aditya Kali wrote:
>>> On Fri, Jul 18, 2014 at 9:51 AM, Andy Lutomirski
>>> wrote:
On Jul 17, 2014 1:56 PM, "Aditya Kali" wrote:
>
>
On Fri, Jul 18, 2014 at 11:57 AM, Andy Lutomirski wrote:
> On Fri, Jul 18, 2014 at 11:51 AM, Aditya Kali wrote:
>> On Fri, Jul 18, 2014 at 9:51 AM, Andy Lutomirski wrote:
>>> On Jul 17, 2014 1:56 PM, "Aditya Kali" wrote:
On Thu, Jul 17, 2014 at 12:57 PM, Andy Lutomirski
wrote:
On Mon, 21 Jul 2014, Andy Lutomirski wrote:
> On Mon, Jul 21, 2014 at 2:27 PM, Peter Zijlstra wrote:
> > All this is predicated on the fact that syscalls are 'expensive'.
> > Weren't syscalls only 100s of cycles? All this bitmap mucking is far
> > more expensive due to cacheline misses, which due
On Mon, 21 Jul 2014, Peter Zijlstra wrote:
> On Mon, Jul 21, 2014 at 10:16:37PM +0200, Thomas Gleixner wrote:
> > On Mon, 21 Jul 2014, Darren Hart wrote:
> > > We observed some significant improvements under some very specific use
> > > cases, but a more thorough dive into performance impact in
On Mon, 21 Jul 2014, Ingo Molnar wrote:
> * Waiman Long wrote:
>
> > Testing done on a 4-socket Westmere-EX boxes with 40 cores (HT off)
> > showed the following performance data (average kops/s) with various
> > load factor (number of pause instructions) used in the critical
> > section using
On Mon, Jul 21, 2014 at 2:27 PM, Peter Zijlstra wrote:
> On Mon, Jul 21, 2014 at 10:16:37PM +0200, Thomas Gleixner wrote:
>> On Mon, 21 Jul 2014, Darren Hart wrote:
>> > We observed some significant improvements under some very specific use
>> > cases, but a more thorough dive into performance imp
On Mon, Jul 21, 2014 at 10:16:37PM +0200, Thomas Gleixner wrote:
> On Mon, 21 Jul 2014, Darren Hart wrote:
> > We observed some significant improvements under some very specific use
> > cases, but a more thorough dive into performance impact in the other cases
> > as well as security implications w
* Waiman Long wrote:
> Testing done on a 4-socket Westmere-EX boxes with 40 cores (HT off)
> showed the following performance data (average kops/s) with various
> load factor (number of pause instructions) used in the critical
> section using an userspace mutex microbenchmark.
>
> Threads
Hi,
On Fri, 18 Jul 2014, Theodore Ts'o wrote:
[...]
> If the GRND_RANDOM bit is not set, then the /dev/urandom pool
> will be used. Unlike using read(2) to fetch data from
> /dev/urandom, if the urandom pool has not been sufficiently
> initialized, getrandom(2) will block
On Mon, 2014-07-21 at 11:24 -0400, Waiman Long wrote:
> This patch adds code to do optimistic spinning for the FUTEX_SPIN_LOCK
> primitive on the futex value when the lock owner is running. It is
> the same optimistic spinning technique that is done in the mutex and
> rw semaphore code to improve t
On Mon, 21 Jul 2014, Darren Hart wrote:
> We observed some significant improvements under some very specific use
> cases, but a more thorough dive into performance impact in the other cases
> as well as security implications with the vdso is still wanting.
The security implication is that the feat
On Mon, 21 Jul 2014, Andi Kleen wrote:
> Andi Kleen writes:
>
> > Waiman Long writes:
> >
> >> This patch series introduces two new futex command codes to support
> >> a new optimistic spinning futex for implementing an exclusive lock
> >> primitive that should perform better than the same prim
On 7/21/14, 10:20, "Darren Hart" wrote:
>On 7/21/14, 9:45, "Andi Kleen" wrote:
>
>>Andi Kleen writes:
>>
>>> Waiman Long writes:
>>>
This patch series introduces two new futex command codes to support
a new optimistic spinning futex for implementing an exclusive lock
primitive t
On 7/21/14, 9:45, "Andi Kleen" wrote:
>Andi Kleen writes:
>
>> Waiman Long writes:
>>
>>> This patch series introduces two new futex command codes to support
>>> a new optimistic spinning futex for implementing an exclusive lock
>>> primitive that should perform better than the same primitive u
On Mon, 2014-07-21 at 11:24 -0400, Waiman Long wrote:
> This patch adds code to do optimistic spinning for the FUTEX_SPIN_LOCK
> primitive on the futex value when the lock owner is running. It is
> the same optimistic spinning technique that is done in the mutex and
> rw semaphore code to improve t
Andi Kleen writes:
> Waiman Long writes:
>
>> This patch series introduces two new futex command codes to support
>> a new optimistic spinning futex for implementing an exclusive lock
>> primitive that should perform better than the same primitive using
>> the wait-wake futex in cases where the
Waiman Long writes:
> This patch series introduces two new futex command codes to support
> a new optimistic spinning futex for implementing an exclusive lock
> primitive that should perform better than the same primitive using
> the wait-wake futex in cases where the lock owner is actively worki
On Mon, 21 Jul 2014, Waiman Long wrote:
> +#define FUTEX_TID(u) (pid_t)((u) & FUTEX_TID_MASK)
> +#define FUTEX_HAS_WAITERS(u) ((u) & FUTEX_WAITERS)
You love ugly macros, right?
> +/*
> + * futex_spin_trylock - attempt to take the lock
> + * Return: 1 if successful or an error happen
> +
On 07/21/2014 08:24 AM, Waiman Long wrote:
> This patch adds a new document file on how to use the spinning futexes.
>
> Signed-off-by: Waiman Long
> ---
> Documentation/spinning-futex.txt | 109
> ++
> 1 files changed, 109 insertions(+), 0 deletions(-)
> c
This patch adds two new simple exclusive lock and unlock primitives
or command codes (FUTEX_SPIN_LOCK and FUTEX_SPIN_UNLOCK) to provide
to the users of the futex(2) syscall. These two primitives provide
an abstract for a mutual exclusive lock (mutex).
The semantics is about the same as the PI and
A simple FIFO list for the waiting tasks is easy to use. However, it
differs in behavior from the other futex primitives that the waiting
tasks are put in a priority list.
In order to make a sorted list ranked on priority as well as the
order they enter the kernel, we need to convert the simple li
This patch moves a wakened task back to the optimistic spinning loop
if the owner is running.
Signed-off-by: Waiman Long
---
kernel/futex.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index ddc24d1..cca6457 100644
-
This patch adds code to do optimistic spinning for the FUTEX_SPIN_LOCK
primitive on the futex value when the lock owner is running. It is
the same optimistic spinning technique that is done in the mutex and
rw semaphore code to improve their performance especially on large
systems with large number
This patch adds a new document file on how to use the spinning futexes.
Signed-off-by: Waiman Long
---
Documentation/spinning-futex.txt | 109 ++
1 files changed, 109 insertions(+), 0 deletions(-)
create mode 100644 Documentation/spinning-futex.txt
diff --g
This patch series introduces two new futex command codes to support
a new optimistic spinning futex for implementing an exclusive lock
primitive that should perform better than the same primitive using
the wait-wake futex in cases where the lock owner is actively working
instead of waiting for I/O
37 matches
Mail list logo
