On 03/19, Peter Zijlstra wrote:
>
> On Wed, Mar 19, 2014 at 07:44:29PM +, Dilger, Andreas wrote:
> > The original reason for l_wait_event() not using TASK_UNINTERRUPTIBLE
> > is to avoid the load on the server continually being "num_service_threads"
> > regardless of whether they are actually d
On 2014/03/19, 1:55 PM, "Peter Zijlstra" wrote:
>On Wed, Mar 19, 2014 at 07:44:29PM +, Dilger, Andreas wrote:
>> The original reason for l_wait_event() not using TASK_UNINTERRUPTIBLE
>> is to avoid the load on the server continually being
>>"num_service_threads"
>> regardless of whether they
On Wed, Mar 19, 2014 at 07:44:29PM +, Dilger, Andreas wrote:
> The original reason for l_wait_event() not using TASK_UNINTERRUPTIBLE
> is to avoid the load on the server continually being "num_service_threads"
> regardless of whether they are actually doing something or not. We
> added various
On 2014/03/19, 11:33 AM, "Oleg Nesterov" wrote:
>On 03/19, Peng Tao wrote:
>>
>> On Wed, Mar 19, 2014 at 12:23 AM, Oleg Nesterov wrote:
>> >
>> > Firtsly, cfs_block_sigs/cfs_block_sigsinv/etc are not exactly right,
>> > they need set_current_blocked(). And you can read "old" lockless.
>> >
>> It
On 03/19, Peter Zijlstra wrote:
>
> On Wed, Mar 19, 2014 at 05:49:07PM +0100, Oleg Nesterov wrote:
> > +static void add_wait_queue_flag(wait_queue_head_t *q, wait_queue_t *wait)
> > +{
> > + struct list_head *head = &q->task_list;
> > + wait_queue_t *excl;
> > +
> > + if (wait->flags & WQ_FLA
On 03/19, Peng Tao wrote:
>
> On Wed, Mar 19, 2014 at 12:23 AM, Oleg Nesterov wrote:
> >
> > Firtsly, cfs_block_sigs/cfs_block_sigsinv/etc are not exactly right,
> > they need set_current_blocked(). And you can read "old" lockless.
> >
> It seems that set_current_blocked() is not exported. Can we
On Wed, Mar 19, 2014 at 05:49:07PM +0100, Oleg Nesterov wrote:
> +static void add_wait_queue_flag(wait_queue_head_t *q, wait_queue_t *wait)
> +{
> + struct list_head *head = &q->task_list;
> + wait_queue_t *excl;
> +
> + if (wait->flags & WQ_FLAG_EXCLUSIVE) {
> + if (wait->f
On Wed, Mar 19, 2014 at 12:23 AM, Oleg Nesterov wrote:
> On 03/18, Peng Tao wrote:
>>
>> On Tue, Mar 18, 2014 at 10:05 PM, Peter Zijlstra
>> wrote:
>> >
>> > Unless you cannot use ___wait() and really need to open-code the
>> > wait_event() stuff.
>> >
>> Lustre's private l_wait_event() stuff ta
On Tue, Mar 18, 2014 at 11:47 PM, Oleg Nesterov wrote:
> On 03/18, Peter Zijlstra wrote:
>>
>> I think we can avoid the entire function if we add
>> WQ_FLAG_LIFO and make prepare_to_wait_event() DTRT.
>
> Agreed, this looks very natural.
>
> prepare_to_wait_event(WQ_FLAG_LIFO) should probably skip
On 03/18, Peng Tao wrote:
>
> On Tue, Mar 18, 2014 at 10:05 PM, Peter Zijlstra wrote:
> >
> > Unless you cannot use ___wait() and really need to open-code the
> > wait_event() stuff.
> >
> Lustre's private l_wait_event() stuff takes care to (un)mask
> LUSTRE_FATAL_SIGS
Hmm. This is off-topic but
On 03/18, Peter Zijlstra wrote:
>
> I think we can avoid the entire function if we add
> WQ_FLAG_LIFO and make prepare_to_wait_event() DTRT.
Agreed, this looks very natural.
prepare_to_wait_event(WQ_FLAG_LIFO) should probably skip all "flags == 0"
entries before list_add(). Given that it is suppo
On Tue, Mar 18, 2014 at 10:05 PM, Peter Zijlstra wrote:
> On Tue, Mar 18, 2014 at 09:51:04PM +0800, Peng Tao wrote:
>> > Firstly I think the _head postfix for LIFO is a bad name,
>> Do you have any preference on the name? add_wait_queue_exclusive_lifo()?
>
> I think we can avoid the entire functio
On Tue, Mar 18, 2014 at 09:51:04PM +0800, Peng Tao wrote:
> > Firstly I think the _head postfix for LIFO is a bad name,
> Do you have any preference on the name? add_wait_queue_exclusive_lifo()?
I think we can avoid the entire function if we add
WQ_FLAG_LIFO and make prepare_to_wait_event() DTRT.
On Tue, Mar 18, 2014 at 9:33 PM, Peter Zijlstra wrote:
> On Tue, Mar 18, 2014 at 09:10:08PM +0800, Peng Tao wrote:
>> Normally wait_queue_t is a FIFO list for exclusive waiting tasks.
>> As a side effect, if there are many threads waiting on the same
>> condition (which is common for data servers
On Tue, Mar 18, 2014 at 09:10:08PM +0800, Peng Tao wrote:
> Normally wait_queue_t is a FIFO list for exclusive waiting tasks.
> As a side effect, if there are many threads waiting on the same
> condition (which is common for data servers like Lustre), all
> threads will be waken up again and again,
Normally wait_queue_t is a FIFO list for exclusive waiting tasks.
As a side effect, if there are many threads waiting on the same
condition (which is common for data servers like Lustre), all
threads will be waken up again and again, causing unnecessary cache
line polution. Instead of FIFO lists, w
16 matches
Mail list logo
