On Tue, Dec 19 2017, Dilger, Andreas wrote:
> On Dec 18, 2017, at 11:03, Patrick Farrell wrote:
>>
>> The wait calls in ll_statahead_thread are done in a service thread, and
>> should probably *not* contribute to load.
>>
>> The one in osc_extent_wait is perhaps tough - It is
On Tue, Dec 19 2017, Dilger, Andreas wrote:
> On Dec 18, 2017, at 11:03, Patrick Farrell wrote:
>>
>> The wait calls in ll_statahead_thread are done in a service thread, and
>> should probably *not* contribute to load.
>>
>> The one in osc_extent_wait is perhaps tough - It is called both from
On Dec 18, 2017, at 11:03, Patrick Farrell wrote:
>
> The wait calls in ll_statahead_thread are done in a service thread, and
> should probably *not* contribute to load.
>
> The one in osc_extent_wait is perhaps tough - It is called both from user
> threads & daemon threads
On Dec 18, 2017, at 11:03, Patrick Farrell wrote:
>
> The wait calls in ll_statahead_thread are done in a service thread, and
> should probably *not* contribute to load.
>
> The one in osc_extent_wait is perhaps tough - It is called both from user
> threads & daemon threads depending on the
On Mon, Dec 18 2017, Patrick Farrell wrote:
> Ah, finally we¹ve got that NOLOAD flag! This will clear up several nasty
> bugs around ptrace and sigkill that come when waiting with signals blocked
> in TASK_INTERRUPTIBLE. I see it was added in 2015Š The joys of working
> with vendor kernels.
I
On Mon, Dec 18 2017, Patrick Farrell wrote:
> Ah, finally we¹ve got that NOLOAD flag! This will clear up several nasty
> bugs around ptrace and sigkill that come when waiting with signals blocked
> in TASK_INTERRUPTIBLE. I see it was added in 2015Š The joys of working
> with vendor kernels.
I
The wait calls in ll_statahead_thread are done in a service thread, and
should probably *not* contribute to load.
The one in osc_extent_wait is perhaps tough - It is called both from user
threads & daemon threads depending on the situation. The effect of adding
that to load average could be
The wait calls in ll_statahead_thread are done in a service thread, and
should probably *not* contribute to load.
The one in osc_extent_wait is perhaps tough - It is called both from user
threads & daemon threads depending on the situation. The effect of adding
that to load average could be
Ah, finally we¹ve got that NOLOAD flag! This will clear up several nasty
bugs around ptrace and sigkill that come when waiting with signals blocked
in TASK_INTERRUPTIBLE. I see it was added in 2015Š The joys of working
with vendor kernels.
Thanks for these, Neil. I¹ll try to take a careful
Ah, finally we¹ve got that NOLOAD flag! This will clear up several nasty
bugs around ptrace and sigkill that come when waiting with signals blocked
in TASK_INTERRUPTIBLE. I see it was added in 2015Š The joys of working
with vendor kernels.
Thanks for these, Neil. I¹ll try to take a careful
When the lwi arg is full of zeros, l_wait_event() behaves almost
identically to the standard wait_event() interface, so use that
instead.
The only difference in behavior is that l_wait_event() blocks all
signals and uses an TASK_INTERRUPTIBLE wait, while wait_event()
does not block signals, but
When the lwi arg is full of zeros, l_wait_event() behaves almost
identically to the standard wait_event() interface, so use that
instead.
The only difference in behavior is that l_wait_event() blocks all
signals and uses an TASK_INTERRUPTIBLE wait, while wait_event()
does not block signals, but
12 matches
Mail list logo