On 03/25/2014 05:01 PM, Davidlohr Bueso wrote:
Good timing! The topic came up just yesterday in LSF/MM. This
functionality is on the wish list for both facebook and postgres.
Thanks for letting me know. I am glad to hear of others who need this
functionality. Did you happen to catch the
On Mon, 2014-03-03 at 11:07 -0700, Khalid Aziz wrote:
> I am working on a feature that has been requested by database folks that
> helps with performance. Some of the oft executed database code uses
> mutexes to lock other threads out of a critical section. They often see
> a situation where a
On Mon, 2014-03-03 at 11:07 -0700, Khalid Aziz wrote:
I am working on a feature that has been requested by database folks that
helps with performance. Some of the oft executed database code uses
mutexes to lock other threads out of a critical section. They often see
a situation where a thread
On 03/25/2014 05:01 PM, Davidlohr Bueso wrote:
Good timing! The topic came up just yesterday in LSF/MM. This
functionality is on the wish list for both facebook and postgres.
Thanks for letting me know. I am glad to hear of others who need this
functionality. Did you happen to catch the
On Thu, Mar 06, 2014 at 02:59:46PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 06, 2014 at 11:13:33PM +1100, Kevin Easton wrote:
> > On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
> > > Anything else?
> >
> > If it was possible to make the time remaining in the current timeslice
> >
On 03/06/2014 04:14 AM, Thomas Gleixner wrote:
We understand that you want to avoid preemption in the first place and
not getting into the contention handling case.
But, what you're trying to do is essentially creating an ABI which we
have to support and maintain forever. And that definitely is
On 03/06/2014 07:25 AM, David Lang wrote:
On Thu, 6 Mar 2014, Kevin Easton wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
If it was possible to make the time remaining in the current timeslice
available to userspace through the vdso, the thread could do
On 03/06/2014 02:57 AM, Peter Zijlstra wrote:
On Wed, Mar 05, 2014 at 12:58:29PM -0700, Khalid Aziz wrote:
Looking at the current problem I am trying to
solve with databases and JVM, I run into the same issue I described in my
earlier email. Proxy execution is a post-contention solution. By the
The no checking is omitting access_ok(), no? Either way, disabling page faults
have to be done explicitly.
On March 6, 2014 6:33:04 AM PST, Thomas Gleixner wrote:
>
>
>On Thu, 6 Mar 2014, Peter Zijlstra wrote:
>
>> On Thu, Mar 06, 2014 at 02:45:00PM +0100, Rasmus Villemoes wrote:
>> > Peter
On Thu, 6 Mar 2014, Peter Zijlstra wrote:
> On Thu, Mar 06, 2014 at 02:45:00PM +0100, Rasmus Villemoes wrote:
> > Peter Zijlstra writes:
> >
> > > On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
> > >> Is it possible to implement non-sleeping versions of {get,put}_user()?
>
On Thu, 6 Mar 2014, Kevin Easton wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
If it was possible to make the time remaining in the current timeslice
available to userspace through the vdso, the thread could do something like:
if (sys_timeleft() <
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 05:36 PM, David Lang wrote:
Yes, you pay for two context switches, but you don't pay for threads
B..ZZZ all running (and potentially spinning) trying to aquire the lock
before thread A is able to complete it's work.
Ah, great. We are
On Thu, 6 Mar 2014, Rasmus Villemoes wrote:
> Peter Zijlstra writes:
>
> > On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
> >> Is it possible to implement non-sleeping versions of {get,put}_user()?
> >
> > __{get,put}_user()
>
> Huh?
>
> arch/x86/include/asm/uaccess.h:
>
>
On Thu, Mar 06, 2014 at 02:45:00PM +0100, Rasmus Villemoes wrote:
> Peter Zijlstra writes:
>
> > On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
> >> Is it possible to implement non-sleeping versions of {get,put}_user()?
> >
> > __{get,put}_user()
>
> Huh?
>
>
On Thu, Mar 06, 2014 at 11:13:33PM +1100, Kevin Easton wrote:
> On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
> > Anything else?
>
> If it was possible to make the time remaining in the current timeslice
> available to userspace through the vdso, the thread could do something like:
Peter Zijlstra writes:
> On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
>> Is it possible to implement non-sleeping versions of {get,put}_user()?
>
> __{get,put}_user()
Huh?
arch/x86/include/asm/uaccess.h:
/**
* __get_user: - Get a simple variable from user space, with
On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
> Is it possible to implement non-sleeping versions of {get,put}_user()?
__{get,put}_user()
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
"H. Peter Anvin" writes:
> I have several issues with this interface:
>
> 1. First, a process needs to know if it *should* have been preempted
> before it calls sched_yield(). So there needs to be a second flag set
> by the scheduler when granting amnesty.
>
> 2. A process which fails to call
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
> Anything else?
If it was possible to make the time remaining in the current timeslice
available to userspace through the vdso, the thread could do something like:
if (sys_timeleft() < CRITICAL_SECTION_SIZE)
yield();
lock();
to
On Wed, 5 Mar 2014, Khalid Aziz wrote:
> On 03/05/2014 04:10 AM, Peter Zijlstra wrote:
> > On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
> > > Anything else?
> >
> > Proxy execution; its a form of PI that works for arbitrary scheduling
> > policies (thus also very much including
On Wed, Mar 05, 2014 at 12:58:29PM -0700, Khalid Aziz wrote:
> On 03/05/2014 04:10 AM, Peter Zijlstra wrote:
> >On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
> >>Anything else?
> >
> >Proxy execution; its a form of PI that works for arbitrary scheduling
> >policies (thus also very
On Wed, Mar 05, 2014 at 12:58:29PM -0700, Khalid Aziz wrote:
On 03/05/2014 04:10 AM, Peter Zijlstra wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
Proxy execution; its a form of PI that works for arbitrary scheduling
policies (thus also very much including
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 04:10 AM, Peter Zijlstra wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
Proxy execution; its a form of PI that works for arbitrary scheduling
policies (thus also very much including fair).
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
If it was possible to make the time remaining in the current timeslice
available to userspace through the vdso, the thread could do something like:
if (sys_timeleft() CRITICAL_SECTION_SIZE)
yield();
lock();
to
H. Peter Anvin h...@zytor.com writes:
I have several issues with this interface:
1. First, a process needs to know if it *should* have been preempted
before it calls sched_yield(). So there needs to be a second flag set
by the scheduler when granting amnesty.
2. A process which fails to
On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
Is it possible to implement non-sleeping versions of {get,put}_user()?
__{get,put}_user()
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
Peter Zijlstra pet...@infradead.org writes:
On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
Is it possible to implement non-sleeping versions of {get,put}_user()?
__{get,put}_user()
Huh?
arch/x86/include/asm/uaccess.h:
/**
* __get_user: - Get a simple variable from user
On Thu, Mar 06, 2014 at 11:13:33PM +1100, Kevin Easton wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
If it was possible to make the time remaining in the current timeslice
available to userspace through the vdso, the thread could do something like:
On Thu, Mar 06, 2014 at 02:45:00PM +0100, Rasmus Villemoes wrote:
Peter Zijlstra pet...@infradead.org writes:
On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
Is it possible to implement non-sleeping versions of {get,put}_user()?
__{get,put}_user()
Huh?
On Thu, 6 Mar 2014, Rasmus Villemoes wrote:
Peter Zijlstra pet...@infradead.org writes:
On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
Is it possible to implement non-sleeping versions of {get,put}_user()?
__{get,put}_user()
Huh?
arch/x86/include/asm/uaccess.h:
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 05:36 PM, David Lang wrote:
Yes, you pay for two context switches, but you don't pay for threads
B..ZZZ all running (and potentially spinning) trying to aquire the lock
before thread A is able to complete it's work.
Ah, great. We are
On Thu, 6 Mar 2014, Kevin Easton wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
If it was possible to make the time remaining in the current timeslice
available to userspace through the vdso, the thread could do something like:
if (sys_timeleft()
On Thu, 6 Mar 2014, Peter Zijlstra wrote:
On Thu, Mar 06, 2014 at 02:45:00PM +0100, Rasmus Villemoes wrote:
Peter Zijlstra pet...@infradead.org writes:
On Thu, Mar 06, 2014 at 02:24:43PM +0100, Rasmus Villemoes wrote:
Is it possible to implement non-sleeping versions of
The no checking is omitting access_ok(), no? Either way, disabling page faults
have to be done explicitly.
On March 6, 2014 6:33:04 AM PST, Thomas Gleixner t...@linutronix.de wrote:
On Thu, 6 Mar 2014, Peter Zijlstra wrote:
On Thu, Mar 06, 2014 at 02:45:00PM +0100, Rasmus Villemoes wrote:
On 03/06/2014 02:57 AM, Peter Zijlstra wrote:
On Wed, Mar 05, 2014 at 12:58:29PM -0700, Khalid Aziz wrote:
Looking at the current problem I am trying to
solve with databases and JVM, I run into the same issue I described in my
earlier email. Proxy execution is a post-contention solution. By the
On 03/06/2014 07:25 AM, David Lang wrote:
On Thu, 6 Mar 2014, Kevin Easton wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
If it was possible to make the time remaining in the current timeslice
available to userspace through the vdso, the thread could do
On 03/06/2014 04:14 AM, Thomas Gleixner wrote:
We understand that you want to avoid preemption in the first place and
not getting into the contention handling case.
But, what you're trying to do is essentially creating an ABI which we
have to support and maintain forever. And that definitely is
On Thu, Mar 06, 2014 at 02:59:46PM +0100, Peter Zijlstra wrote:
On Thu, Mar 06, 2014 at 11:13:33PM +1100, Kevin Easton wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
If it was possible to make the time remaining in the current timeslice
available to
On 03/05/2014 05:36 PM, David Lang wrote:
Yes, you pay for two context switches, but you don't pay for threads
B..ZZZ all running (and potentially spinning) trying to aquire the lock
before thread A is able to complete it's work.
Ah, great. We are converging now.
As soon as a second thread
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 04:59 PM, David Lang wrote:
what's the cost to setup mmap of this file in /proc. this is sounding
like a lot of work.
That is a one time cost paid when a thread initializes itself.
is this gain from not giving up the CPU at all? or is
On 03/05/2014 04:59 PM, David Lang wrote:
what's the cost to setup mmap of this file in /proc. this is sounding
like a lot of work.
That is a one time cost paid when a thread initializes itself.
is this gain from not giving up the CPU at all? or is it from avoiding
all the delays due to
On 03/05/2014 04:02 PM, Khalid Aziz wrote:
>
> Yes, you had made that suggestion earlier and I like it. It will be in
> v2 patch. I am thinking of making the penalty be denial of next
> preemption immunity request if a process fails to yield when it should
> have. Sounds good?
>
That is the
On 03/05/2014 04:56 PM, H. Peter Anvin wrote:
On 03/05/2014 03:48 PM, Khalid Aziz wrote:
Cost is writing to a memory location since thread is using mmap, not
insignificant but hardly expensive. Thread does not need to know how
much time it has left in current timeslice. It always sets the flag
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 04:13 PM, David Lang wrote:
Yes, you have paid the cost of the context switch, but your original
problem description talked about having multiple other threads trying to
get the lock, then spinning trying to get the lock (wasting time if the
On 03/05/2014 03:48 PM, Khalid Aziz wrote:
>
> Cost is writing to a memory location since thread is using mmap, not
> insignificant but hardly expensive. Thread does not need to know how
> much time it has left in current timeslice. It always sets the flag to
> request pre-emption immunity before
On 03/05/2014 04:13 PM, David Lang wrote:
Yes, you have paid the cost of the context switch, but your original
problem description talked about having multiple other threads trying to
get the lock, then spinning trying to get the lock (wasting time if the
process holding it is asleep, but not if
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 09:36 AM, Oleg Nesterov wrote:
On 03/05, Andi Kleen wrote:
On Wed, Mar 05, 2014 at 03:54:20PM +0100, Oleg Nesterov wrote:
On 03/04, Andi Kleen wrote:
Anything else?
Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
On 03/05/2014 04:10 AM, Peter Zijlstra wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
Proxy execution; its a form of PI that works for arbitrary scheduling
policies (thus also very much including fair).
With that what you effectively end up with is the lock
On 03/05/2014 04:10 AM, Peter Zijlstra wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
Proxy execution; its a form of PI that works for arbitrary scheduling
policies (thus also very much including fair).
With that what you effectively end up with is the lock
On 03/05/2014 09:36 AM, Oleg Nesterov wrote:
On 03/05, Andi Kleen wrote:
On Wed, Mar 05, 2014 at 03:54:20PM +0100, Oleg Nesterov wrote:
On 03/04, Andi Kleen wrote:
Anything else?
Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
Or perhaps sys_futex() can do this if it
On 03/05/2014 09:12 AM, Oleg Nesterov wrote:
On 03/05, Oleg Nesterov wrote:
You added /proc/sched_preempt_delay to avoid the syscall. I think it
would be better to simply add vdso_sched_preempt_delay() instead.
I am stupid. vdso_sched_preempt_delay() obviously can't write to, say,
On 03/05, Oleg Nesterov wrote:
>
> You added /proc/sched_preempt_delay to avoid the syscall. I think it
> would be better to simply add vdso_sched_preempt_delay() instead.
I am stupid. vdso_sched_preempt_delay() obviously can't write to, say,
task_struct.
Oleg.
--
To unsubscribe from this list:
On 03/05, Andi Kleen wrote:
>
> On Wed, Mar 05, 2014 at 03:54:20PM +0100, Oleg Nesterov wrote:
> > On 03/04, Andi Kleen wrote:
> > >
> > > Anything else?
> >
> > Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
> > Or perhaps sys_futex() can do this if it knows the owner. Don't
On Wed, Mar 05, 2014 at 03:54:20PM +0100, Oleg Nesterov wrote:
> On 03/04, Andi Kleen wrote:
> >
> > Anything else?
>
> Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
> Or perhaps sys_futex() can do this if it knows the owner. Don't ask
> me what exactly I mean though ;)
On 03/04, Andi Kleen wrote:
>
> Anything else?
Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
Or perhaps sys_futex() can do this if it knows the owner. Don't ask
me what exactly I mean though ;)
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe
On 03/04, Khalid Aziz wrote:
>
> On 03/04/2014 12:03 PM, Oleg Nesterov wrote:
>>
>> 1. mremap() can move this vma, so do_exit() can't trust ->uaddr
>>
>> 2. Even worse, mremap() itself is not safe. It can do ->close()
>> too and create the new vma with the same vm_ops. Another
>>
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
> Anything else?
Proxy execution; its a form of PI that works for arbitrary scheduling
policies (thus also very much including fair).
With that what you effectively end up with is the lock holder running
'boosted' by the runtime of its
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
Proxy execution; its a form of PI that works for arbitrary scheduling
policies (thus also very much including fair).
With that what you effectively end up with is the lock holder running
'boosted' by the runtime of its
On 03/04, Khalid Aziz wrote:
On 03/04/2014 12:03 PM, Oleg Nesterov wrote:
1. mremap() can move this vma, so do_exit() can't trust -uaddr
2. Even worse, mremap() itself is not safe. It can do -close()
too and create the new vma with the same vm_ops. Another
unmap
On 03/04, Andi Kleen wrote:
Anything else?
Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
Or perhaps sys_futex() can do this if it knows the owner. Don't ask
me what exactly I mean though ;)
Oleg.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wed, Mar 05, 2014 at 03:54:20PM +0100, Oleg Nesterov wrote:
On 03/04, Andi Kleen wrote:
Anything else?
Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
Or perhaps sys_futex() can do this if it knows the owner. Don't ask
me what exactly I mean though ;)
You mean
On 03/05, Andi Kleen wrote:
On Wed, Mar 05, 2014 at 03:54:20PM +0100, Oleg Nesterov wrote:
On 03/04, Andi Kleen wrote:
Anything else?
Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
Or perhaps sys_futex() can do this if it knows the owner. Don't ask
me what
On 03/05, Oleg Nesterov wrote:
You added /proc/sched_preempt_delay to avoid the syscall. I think it
would be better to simply add vdso_sched_preempt_delay() instead.
I am stupid. vdso_sched_preempt_delay() obviously can't write to, say,
task_struct.
Oleg.
--
To unsubscribe from this list:
On 03/05/2014 09:12 AM, Oleg Nesterov wrote:
On 03/05, Oleg Nesterov wrote:
You added /proc/sched_preempt_delay to avoid the syscall. I think it
would be better to simply add vdso_sched_preempt_delay() instead.
I am stupid. vdso_sched_preempt_delay() obviously can't write to, say,
On 03/05/2014 09:36 AM, Oleg Nesterov wrote:
On 03/05, Andi Kleen wrote:
On Wed, Mar 05, 2014 at 03:54:20PM +0100, Oleg Nesterov wrote:
On 03/04, Andi Kleen wrote:
Anything else?
Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
Or perhaps sys_futex() can do this if it
On 03/05/2014 04:10 AM, Peter Zijlstra wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
Proxy execution; its a form of PI that works for arbitrary scheduling
policies (thus also very much including fair).
With that what you effectively end up with is the lock
On 03/05/2014 04:10 AM, Peter Zijlstra wrote:
On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote:
Anything else?
Proxy execution; its a form of PI that works for arbitrary scheduling
policies (thus also very much including fair).
With that what you effectively end up with is the lock
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 09:36 AM, Oleg Nesterov wrote:
On 03/05, Andi Kleen wrote:
On Wed, Mar 05, 2014 at 03:54:20PM +0100, Oleg Nesterov wrote:
On 03/04, Andi Kleen wrote:
Anything else?
Well, we have yield_to(). Perhaps sys_yield_to(lock_owner) can help.
On 03/05/2014 04:13 PM, David Lang wrote:
Yes, you have paid the cost of the context switch, but your original
problem description talked about having multiple other threads trying to
get the lock, then spinning trying to get the lock (wasting time if the
process holding it is asleep, but not if
On 03/05/2014 03:48 PM, Khalid Aziz wrote:
Cost is writing to a memory location since thread is using mmap, not
insignificant but hardly expensive. Thread does not need to know how
much time it has left in current timeslice. It always sets the flag to
request pre-emption immunity before
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 04:13 PM, David Lang wrote:
Yes, you have paid the cost of the context switch, but your original
problem description talked about having multiple other threads trying to
get the lock, then spinning trying to get the lock (wasting time if the
On 03/05/2014 04:56 PM, H. Peter Anvin wrote:
On 03/05/2014 03:48 PM, Khalid Aziz wrote:
Cost is writing to a memory location since thread is using mmap, not
insignificant but hardly expensive. Thread does not need to know how
much time it has left in current timeslice. It always sets the flag
On 03/05/2014 04:02 PM, Khalid Aziz wrote:
Yes, you had made that suggestion earlier and I like it. It will be in
v2 patch. I am thinking of making the penalty be denial of next
preemption immunity request if a process fails to yield when it should
have. Sounds good?
That is the minimum
On 03/05/2014 04:59 PM, David Lang wrote:
what's the cost to setup mmap of this file in /proc. this is sounding
like a lot of work.
That is a one time cost paid when a thread initializes itself.
is this gain from not giving up the CPU at all? or is it from avoiding
all the delays due to
On Wed, 5 Mar 2014, Khalid Aziz wrote:
On 03/05/2014 04:59 PM, David Lang wrote:
what's the cost to setup mmap of this file in /proc. this is sounding
like a lot of work.
That is a one time cost paid when a thread initializes itself.
is this gain from not giving up the CPU at all? or is
On 03/05/2014 05:36 PM, David Lang wrote:
Yes, you pay for two context switches, but you don't pay for threads
B..ZZZ all running (and potentially spinning) trying to aquire the lock
before thread A is able to complete it's work.
Ah, great. We are converging now.
As soon as a second thread
Thomas Gleixner writes:
> On Tue, 4 Mar 2014, Khalid Aziz wrote:
>> be in the right control group. Besides they want to use a common mechanism
>> across multiple OSs and pre-emption delay is already in use on other OSs.
>> Good
>> idea though.
>
> Well, just because preemption delay is a
On Tue, 4 Mar 2014, Khalid Aziz wrote:
> be in the right control group. Besides they want to use a common mechanism
> across multiple OSs and pre-emption delay is already in use on other OSs. Good
> idea though.
Well, just because preemption delay is a mechanism exposed by some
other OS does not
On 03/04/2014 03:23 PM, One Thousand Gnomes wrote:
Obvious bug
| Usage model is a thread mmaps this file during initialization. It then
| writes a 1 to the mmap'd file after it grabs the lock in its critical
| section where it wants immunity from pre-emption.
You need to write it first or you
Obvious bug
| Usage model is a thread mmaps this file during initialization. It then
| writes a 1 to the mmap'd file after it grabs the lock in its critical
| section where it wants immunity from pre-emption.
You need to write it first or you can be pre-empted taking the lock
before asking for
On 03/04/2014 02:12 PM, H. Peter Anvin wrote:
Shades of the Android wakelocks, no?
This seems to effectively give userspace an option to turn preemptive
multitasking into cooperative multitasking, which of course is
unacceptable for a privileged process (the same reason why unprivileged
On 03/03/2014 10:07 AM, Khalid Aziz wrote:
>
> I am working on a feature that has been requested by database folks that
> helps with performance. Some of the oft executed database code uses
> mutexes to lock other threads out of a critical section. They often see
> a situation where a thread
On 03/04/2014 12:03 PM, Oleg Nesterov wrote:
On 03/04, Khalid Aziz wrote:
On 03/04/2014 06:56 AM, Oleg Nesterov wrote:
Hmm. In fact I think do_exit() should crash after munmap? ->mmap_state
should be NULL ?? Perhaps I misread this patch completely...
do_exit() unmaps mmap_state->uaddr, and
On 03/04, Khalid Aziz wrote:
>
> On 03/04/2014 06:56 AM, Oleg Nesterov wrote:
>> Hmm. In fact I think do_exit() should crash after munmap? ->mmap_state
>> should be NULL ?? Perhaps I misread this patch completely...
>
> do_exit() unmaps mmap_state->uaddr, and frees up mmap_state->kaddr and
>
On Tue, 2014-03-04 at 18:38 +, Al Viro wrote:
> On Tue, Mar 04, 2014 at 10:44:54AM -0700, Khalid Aziz wrote:
>
> > do_exit() unmaps mmap_state->uaddr, and frees up mmap_state->kaddr
> > and mmap_state. mmap_state should not be NULL after unmap. vfree()
> > and kfree() are tolerant of pointers
On Tue, Mar 04, 2014 at 10:44:54AM -0700, Khalid Aziz wrote:
> do_exit() unmaps mmap_state->uaddr, and frees up mmap_state->kaddr
> and mmap_state. mmap_state should not be NULL after unmap. vfree()
> and kfree() are tolerant of pointers that have already been freed.
Huh? Double free() is a
Thanks for the review. Please see my comments inline below.
On 03/04/2014 06:56 AM, Oleg Nesterov wrote:
On 03/03, Khalid Aziz wrote:
kernel/sched/preempt_delay.c| 39 ++
Why? This can go into proc/ as well.
Sure. No strong reason to keep these functions in
On 03/03, Khalid Aziz wrote:
>
> This queueing
> and subsequent CPU cycle wastage can be avoided if the locking thread
> could request to be granted an additional timeslice if its current
> timeslice runs out before it gives up the lock.
Well. I am in no position to discuss the changes in
On 03/03, Khalid Aziz wrote:
This queueing
and subsequent CPU cycle wastage can be avoided if the locking thread
could request to be granted an additional timeslice if its current
timeslice runs out before it gives up the lock.
Well. I am in no position to discuss the changes in
Thanks for the review. Please see my comments inline below.
On 03/04/2014 06:56 AM, Oleg Nesterov wrote:
On 03/03, Khalid Aziz wrote:
kernel/sched/preempt_delay.c| 39 ++
Why? This can go into proc/ as well.
Sure. No strong reason to keep these functions in
On Tue, Mar 04, 2014 at 10:44:54AM -0700, Khalid Aziz wrote:
do_exit() unmaps mmap_state-uaddr, and frees up mmap_state-kaddr
and mmap_state. mmap_state should not be NULL after unmap. vfree()
and kfree() are tolerant of pointers that have already been freed.
Huh? Double free() is a bug,
On Tue, 2014-03-04 at 18:38 +, Al Viro wrote:
On Tue, Mar 04, 2014 at 10:44:54AM -0700, Khalid Aziz wrote:
do_exit() unmaps mmap_state-uaddr, and frees up mmap_state-kaddr
and mmap_state. mmap_state should not be NULL after unmap. vfree()
and kfree() are tolerant of pointers that have
On 03/04, Khalid Aziz wrote:
On 03/04/2014 06:56 AM, Oleg Nesterov wrote:
Hmm. In fact I think do_exit() should crash after munmap? -mmap_state
should be NULL ?? Perhaps I misread this patch completely...
do_exit() unmaps mmap_state-uaddr, and frees up mmap_state-kaddr and
mmap_state.
On 03/04/2014 12:03 PM, Oleg Nesterov wrote:
On 03/04, Khalid Aziz wrote:
On 03/04/2014 06:56 AM, Oleg Nesterov wrote:
Hmm. In fact I think do_exit() should crash after munmap? -mmap_state
should be NULL ?? Perhaps I misread this patch completely...
do_exit() unmaps mmap_state-uaddr, and
On 03/03/2014 10:07 AM, Khalid Aziz wrote:
I am working on a feature that has been requested by database folks that
helps with performance. Some of the oft executed database code uses
mutexes to lock other threads out of a critical section. They often see
a situation where a thread grabs the
On 03/04/2014 02:12 PM, H. Peter Anvin wrote:
Shades of the Android wakelocks, no?
This seems to effectively give userspace an option to turn preemptive
multitasking into cooperative multitasking, which of course is
unacceptable for a privileged process (the same reason why unprivileged
Obvious bug
| Usage model is a thread mmaps this file during initialization. It then
| writes a 1 to the mmap'd file after it grabs the lock in its critical
| section where it wants immunity from pre-emption.
You need to write it first or you can be pre-empted taking the lock
before asking for
On 03/04/2014 03:23 PM, One Thousand Gnomes wrote:
Obvious bug
| Usage model is a thread mmaps this file during initialization. It then
| writes a 1 to the mmap'd file after it grabs the lock in its critical
| section where it wants immunity from pre-emption.
You need to write it first or you
On Tue, 4 Mar 2014, Khalid Aziz wrote:
be in the right control group. Besides they want to use a common mechanism
across multiple OSs and pre-emption delay is already in use on other OSs. Good
idea though.
Well, just because preemption delay is a mechanism exposed by some
other OS does not
Thomas Gleixner t...@linutronix.de writes:
On Tue, 4 Mar 2014, Khalid Aziz wrote:
be in the right control group. Besides they want to use a common mechanism
across multiple OSs and pre-emption delay is already in use on other OSs.
Good
idea though.
Well, just because preemption delay is a
1 - 100 of 106 matches
Mail list logo
