On Tue, 14 Apr 2015, Mathieu Desnoyers wrote:
> If we go for a single active flag at a time, I would call that
> "cmd" rather than "flags". Each command would be a power
> of two. Only one cmd could be passed as argument (no "or" mask).
> QUERY would return a mask of the supported commands.
- Original Message -
> On Tue, 14 Apr 2015, Mathieu Desnoyers wrote:
> > Thinking about it a bit more, one reason for doing the QUERY along
> > with the exact set of flags queried allow us to do more than just
> > returning which flags are supported: it allows us to tell userspace
> >
On Tue, 14 Apr 2015, Mathieu Desnoyers wrote:
> Thinking about it a bit more, one reason for doing the QUERY along
> with the exact set of flags queried allow us to do more than just
> returning which flags are supported: it allows us to tell userspace
> whether the combination of flags used is
On Tue, 14 Apr 2015, Mathieu Desnoyers wrote:
> So the question would be: should we introduce this syscall
> in different patches for each architecture, or should
> we add them all in one go ? There is nothing fundamentally
> x86-specific to the implementation of this system call.
We can add that
- Original Message -
> - Original Message -
> > On Mon, 13 Apr 2015, Mathieu Desnoyers wrote:
> >
> > > [ Andrew, can you take this for the 4.1 merge window ? ]
> >
> > You probably mean 4.2, right?
>
> It can wait for 4.2 if you think it still need some work,
> of course. I was
- Original Message -
> On Mon, 13 Apr 2015, Mathieu Desnoyers wrote:
>
> > [ Andrew, can you take this for the 4.1 merge window ? ]
>
> You probably mean 4.2, right?
It can wait for 4.2 if you think it still need some work,
of course. I was submitting it for 4.1 because I thought
the
- Original Message -
On Mon, 13 Apr 2015, Mathieu Desnoyers wrote:
[ Andrew, can you take this for the 4.1 merge window ? ]
You probably mean 4.2, right?
It can wait for 4.2 if you think it still need some work,
of course. I was submitting it for 4.1 because I thought
the
- Original Message -
- Original Message -
On Mon, 13 Apr 2015, Mathieu Desnoyers wrote:
[ Andrew, can you take this for the 4.1 merge window ? ]
You probably mean 4.2, right?
It can wait for 4.2 if you think it still need some work,
of course. I was submitting it
On Tue, 14 Apr 2015, Mathieu Desnoyers wrote:
Thinking about it a bit more, one reason for doing the QUERY along
with the exact set of flags queried allow us to do more than just
returning which flags are supported: it allows us to tell userspace
whether the combination of flags used is valid
- Original Message -
On Tue, 14 Apr 2015, Mathieu Desnoyers wrote:
Thinking about it a bit more, one reason for doing the QUERY along
with the exact set of flags queried allow us to do more than just
returning which flags are supported: it allows us to tell userspace
whether the
On Tue, 14 Apr 2015, Mathieu Desnoyers wrote:
So the question would be: should we introduce this syscall
in different patches for each architecture, or should
we add them all in one go ? There is nothing fundamentally
x86-specific to the implementation of this system call.
We can add that in
On Tue, 14 Apr 2015, Mathieu Desnoyers wrote:
If we go for a single active flag at a time, I would call that
cmd rather than flags. Each command would be a power
of two. Only one cmd could be passed as argument (no or mask).
QUERY would return a mask of the supported commands.
That's what I
On Mon, 13 Apr 2015, Thomas Gleixner wrote:
> On Mon, 13 Apr 2015, Mathieu Desnoyers wrote:
>
> > [ Andrew, can you take this for the 4.1 merge window ? ]
>
> You probably mean 4.2, right?
>
> This fails the basic test for exposure in linux-next, adds syscalls
> without the explicit ack of any
On Mon, 13 Apr 2015, Mathieu Desnoyers wrote:
> [ Andrew, can you take this for the 4.1 merge window ? ]
You probably mean 4.2, right?
This fails the basic test for exposure in linux-next, adds syscalls
without the explicit ack of any x86 maintainer and exposes a user
space ABI with a magic
[ Andrew, can you take this for the 4.1 merge window ? ]
Here is an implementation of a new system call, sys_membarrier(), which
executes a memory barrier on all threads running on the system. It is
implemented by calling synchronize_sched(). It can be used to distribute
the cost of user-space
[ Andrew, can you take this for the 4.1 merge window ? ]
Here is an implementation of a new system call, sys_membarrier(), which
executes a memory barrier on all threads running on the system. It is
implemented by calling synchronize_sched(). It can be used to distribute
the cost of user-space
On Mon, 13 Apr 2015, Mathieu Desnoyers wrote:
[ Andrew, can you take this for the 4.1 merge window ? ]
You probably mean 4.2, right?
This fails the basic test for exposure in linux-next, adds syscalls
without the explicit ack of any x86 maintainer and exposes a user
space ABI with a magic
On Mon, 13 Apr 2015, Thomas Gleixner wrote:
On Mon, 13 Apr 2015, Mathieu Desnoyers wrote:
[ Andrew, can you take this for the 4.1 merge window ? ]
You probably mean 4.2, right?
This fails the basic test for exposure in linux-next, adds syscalls
without the explicit ack of any x86
On Wed, Mar 25, 2015 at 03:03:47PM -0400, Mathieu Desnoyers wrote:
> Here is an implementation of a new system call, sys_membarrier(), which
> executes a memory barrier on all threads running on the system. It is
> implemented by calling synchronize_sched(). It can be used to distribute
> the cost
On Wed, Mar 25, 2015 at 03:03:47PM -0400, Mathieu Desnoyers wrote:
Here is an implementation of a new system call, sys_membarrier(), which
executes a memory barrier on all threads running on the system. It is
implemented by calling synchronize_sched(). It can be used to distribute
the cost of
Here is an implementation of a new system call, sys_membarrier(), which
executes a memory barrier on all threads running on the system. It is
implemented by calling synchronize_sched(). It can be used to distribute
the cost of user-space memory barriers asymmetrically by transforming
pairs of
Here is an implementation of a new system call, sys_membarrier(), which
executes a memory barrier on all threads running on the system. It is
implemented by calling synchronize_sched(). It can be used to distribute
the cost of user-space memory barriers asymmetrically by transforming
pairs of
22 matches
Mail list logo
