Hi,
2013/1/18 Oleg Nesterov :
>
> I can't understand why do you dislike Ivo's simple patch. There are
> a lot of "if (waitqueue_active) wake_up" examples. Even if we add the
> new helpers (personally I don't think this makes sense) , we can do
> this later. Why should we delay this fix?
>
FYI:
On 01/18/2013 09:15 PM, Oleg Nesterov wrote:
> On 01/17, Preeti U Murthy wrote:
>>
>> On 01/16/2013 05:32 PM, Ivo Sieben wrote:
>>>
>>> I don't have a problem that there is a context switch to the high
>>> priority process: it has a higher priority, so it probably is more
>>> important.
>>> My
On 01/18/2013 09:15 PM, Oleg Nesterov wrote:
On 01/17, Preeti U Murthy wrote:
On 01/16/2013 05:32 PM, Ivo Sieben wrote:
I don't have a problem that there is a context switch to the high
priority process: it has a higher priority, so it probably is more
important.
My problem is that even
Hi,
2013/1/18 Oleg Nesterov o...@redhat.com:
I can't understand why do you dislike Ivo's simple patch. There are
a lot of if (waitqueue_active) wake_up examples. Even if we add the
new helpers (personally I don't think this makes sense) , we can do
this later. Why should we delay this fix?
On 01/17, Preeti U Murthy wrote:
>
> On 01/16/2013 05:32 PM, Ivo Sieben wrote:
> >
> > I don't have a problem that there is a context switch to the high
> > priority process: it has a higher priority, so it probably is more
> > important.
> > My problem is that even when the waitqueue is empty,
On 01/17, Preeti U Murthy wrote:
On 01/16/2013 05:32 PM, Ivo Sieben wrote:
I don't have a problem that there is a context switch to the high
priority process: it has a higher priority, so it probably is more
important.
My problem is that even when the waitqueue is empty, the high
On 01/16/2013 05:32 PM, Ivo Sieben wrote:
> 2013/1/16 Preeti U Murthy :
>>
>> Yes.Thank you very much for the explanation :) But I dont see how the
>> context switching goes away with your patch.With your patch, when the
>> higher priority thread comes in when the lower priority thread is
>>
On 01/16/2013 05:32 PM, Ivo Sieben wrote:
2013/1/16 Preeti U Murthy pre...@linux.vnet.ibm.com:
Yes.Thank you very much for the explanation :) But I dont see how the
context switching goes away with your patch.With your patch, when the
higher priority thread comes in when the lower priority
2013/1/16 Preeti U Murthy :
>
> Yes.Thank you very much for the explanation :) But I dont see how the
> context switching goes away with your patch.With your patch, when the
> higher priority thread comes in when the lower priority thread is
> running in the critical section,it will see the wait
Hi Ivo,
On 01/16/2013 02:46 PM, Ivo Sieben wrote:
> Hi Preeti,
>
> 2013/1/16 Preeti U Murthy :
>> Hi Ivo,
>> Can you explain how this problem could create a scheduler overhead?
>> I am a little confused, because as far as i know,scheduler does not come
>> in the picture of the wake up path
Hi Preeti,
2013/1/16 Preeti U Murthy :
> Hi Ivo,
> Can you explain how this problem could create a scheduler overhead?
> I am a little confused, because as far as i know,scheduler does not come
> in the picture of the wake up path right? select_task_rq() in
> try_to_wake_up() is where the
Hi Ivo,
Can you explain how this problem could create a scheduler overhead?
I am a little confused, because as far as i know,scheduler does not come
in the picture of the wake up path right? select_task_rq() in
try_to_wake_up() is where the scheduler comes in,and this is after the
task wakes up.
Hi Ivo,
Can you explain how this problem could create a scheduler overhead?
I am a little confused, because as far as i know,scheduler does not come
in the picture of the wake up path right? select_task_rq() in
try_to_wake_up() is where the scheduler comes in,and this is after the
task wakes up.
Hi Preeti,
2013/1/16 Preeti U Murthy pre...@linux.vnet.ibm.com:
Hi Ivo,
Can you explain how this problem could create a scheduler overhead?
I am a little confused, because as far as i know,scheduler does not come
in the picture of the wake up path right? select_task_rq() in
try_to_wake_up()
Hi Ivo,
On 01/16/2013 02:46 PM, Ivo Sieben wrote:
Hi Preeti,
2013/1/16 Preeti U Murthy pre...@linux.vnet.ibm.com:
Hi Ivo,
Can you explain how this problem could create a scheduler overhead?
I am a little confused, because as far as i know,scheduler does not come
in the picture of the wake
2013/1/16 Preeti U Murthy pre...@linux.vnet.ibm.com:
Yes.Thank you very much for the explanation :) But I dont see how the
context switching goes away with your patch.With your patch, when the
higher priority thread comes in when the lower priority thread is
running in the critical section,it
On 01/15, Ivo Sieben wrote:
>
> It solves an issue for me, and I really would like this patch to be approved.
Agreed.
And even if we want a helper to hide the waitqueue_active(), we can add it
later and convert more users, not just put_ldisc().
Oleg.
--
To unsubscribe from this list: send the
Hi
2013/1/3 Oleg Nesterov :
>> I want to ask you 'scheduler' people for your opinion:
>>
>> Maybe you remember my previous patch where I suggested an extra
>> 'waitqueue empty' check before entering the critical section of the
>> wakeup() function (If you do not remember see
>>
Hi
2013/1/3 Oleg Nesterov o...@redhat.com:
I want to ask you 'scheduler' people for your opinion:
Maybe you remember my previous patch where I suggested an extra
'waitqueue empty' check before entering the critical section of the
wakeup() function (If you do not remember see
On 01/15, Ivo Sieben wrote:
It solves an issue for me, and I really would like this patch to be approved.
Agreed.
And even if we want a helper to hide the waitqueue_active(), we can add it
later and convert more users, not just put_ldisc().
Oleg.
--
To unsubscribe from this list: send the
On 01/03, Ivo Sieben wrote:
>
> Oleg, Peter, Ingo, Andi & Preeti,
>
> 2013/1/2 Jiri Slaby :
> > On 01/02/2013 04:21 PM, Ivo Sieben wrote:
> >> I don't understand your responses: do you suggest to implement this
> >> "if active" behavior in:
> >> * A new wake_up function called wake_up_if_active()
Oleg, Peter, Ingo, Andi & Preeti,
2013/1/2 Jiri Slaby :
> On 01/02/2013 04:21 PM, Ivo Sieben wrote:
>> I don't understand your responses: do you suggest to implement this
>> "if active" behavior in:
>> * A new wake_up function called wake_up_if_active() that is part of
>> the waitqueue layer?
>
>
Oleg, Peter, Ingo, Andi Preeti,
2013/1/2 Jiri Slaby jsl...@suse.cz:
On 01/02/2013 04:21 PM, Ivo Sieben wrote:
I don't understand your responses: do you suggest to implement this
if active behavior in:
* A new wake_up function called wake_up_if_active() that is part of
the waitqueue layer?
On 01/03, Ivo Sieben wrote:
Oleg, Peter, Ingo, Andi Preeti,
2013/1/2 Jiri Slaby jsl...@suse.cz:
On 01/02/2013 04:21 PM, Ivo Sieben wrote:
I don't understand your responses: do you suggest to implement this
if active behavior in:
* A new wake_up function called wake_up_if_active() that
On 01/02/2013 04:21 PM, Ivo Sieben wrote:
> I don't understand your responses: do you suggest to implement this
> "if active" behavior in:
> * A new wake_up function called wake_up_if_active() that is part of
> the waitqueue layer?
Sounds good.
--
js
suse labs
--
To unsubscribe from this list:
Hi Jiri & Alan,
2013/1/2 Alan Cox :
>
>> Looks good, but I would prefer the layer to provide us with
>> wake_up_if_active...
>
> Seconded - this is a problem for the wake up logic in the RT tree. Why
> would we ever do anything else ?
I don't understand your responses: do you suggest to
> Looks good, but I would prefer the layer to provide us with
> wake_up_if_active...
Seconded - this is a problem for the wake up logic in the RT tree. Why
would we ever do anything else ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 12/18/2012 03:48 PM, Ivo Sieben wrote:
> Before waking up the tty line discipline idle queue first check if the queue
> is
> active (non empty). This prevents unnecessary entering the critical section in
> the wake_up() function and therefore avoid needless scheduling overhead on a
>
On 12/18/2012 03:48 PM, Ivo Sieben wrote:
Before waking up the tty line discipline idle queue first check if the queue
is
active (non empty). This prevents unnecessary entering the critical section in
the wake_up() function and therefore avoid needless scheduling overhead on a
PREEMPT_RT
Looks good, but I would prefer the layer to provide us with
wake_up_if_active...
Seconded - this is a problem for the wake up logic in the RT tree. Why
would we ever do anything else ?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Hi Jiri Alan,
2013/1/2 Alan Cox a...@lxorguk.ukuu.org.uk:
Looks good, but I would prefer the layer to provide us with
wake_up_if_active...
Seconded - this is a problem for the wake up logic in the RT tree. Why
would we ever do anything else ?
I don't understand your responses: do you
On 01/02/2013 04:21 PM, Ivo Sieben wrote:
I don't understand your responses: do you suggest to implement this
if active behavior in:
* A new wake_up function called wake_up_if_active() that is part of
the waitqueue layer?
Sounds good.
--
js
suse labs
--
To unsubscribe from this list: send
Before waking up the tty line discipline idle queue first check if the queue is
active (non empty). This prevents unnecessary entering the critical section in
the wake_up() function and therefore avoid needless scheduling overhead on a
PREEMPT_RT system caused by two processes being in the same
Before waking up the tty line discipline idle queue first check if the queue is
active (non empty). This prevents unnecessary entering the critical section in
the wake_up() function and therefore avoid needless scheduling overhead on a
PREEMPT_RT system caused by two processes being in the same
34 matches
Mail list logo
