All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: dedekind1@gmail.com
Cc: peterz@infradead.org, dwmw2@infradead.org,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] UBI: Replace yield() with cond_resched()
Date: Tue, 08 May 2012 12:59:15 +0200	[thread overview]
Message-ID: <4FA8FC83.7000503@nod.at> (raw)
In-Reply-To: <1336467723.23308.23.camel@sauron.fi.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Am 08.05.2012 11:02, schrieb Artem Bityutskiy:
> On Tue, 2012-05-08 at 10:26 +0200, Richard Weinberger wrote:
>> The comment above yield()'s definition says:
>>  * If you want to use yield() to wait for something, use wait_event().
>>  * If you want to use yield() to be 'nice' for others, use cond_resched().
>>  * If you still want to use yield(), do not!
>>
>> The yield() usage of UBI really looks like the "be nice for others" case,
>> so use cond_resched().
>>
>> Signed-off-by: Richard Weinberger <richard@nod.at>
>> CC: peterz@infradead.org
>
> I guess we would better sleep for a couple of hundreds of milliseconds
> instead.

So, you'd prefer a msleep_interruptible(500) instead of yield() in this case?

> The purpose was different. If we have I/O error, we hope it is a
> transient failure. E.g., the HW is temporary unavailable because of an
> internal issue. And with yield() we hoped to schedule away for longer
> time than usual and let other processes which may affect that HW go
> forward and do something.

Okay, yield() is clearly the wrong choice here.
cond_resched() is better.

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org, dwmw2@infradead.org,
	linux-kernel@vger.kernel.org, peterz@infradead.org
Subject: Re: [PATCH] UBI: Replace yield() with cond_resched()
Date: Tue, 08 May 2012 12:59:15 +0200	[thread overview]
Message-ID: <4FA8FC83.7000503@nod.at> (raw)
In-Reply-To: <1336467723.23308.23.camel@sauron.fi.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Am 08.05.2012 11:02, schrieb Artem Bityutskiy:
> On Tue, 2012-05-08 at 10:26 +0200, Richard Weinberger wrote:
>> The comment above yield()'s definition says:
>>  * If you want to use yield() to wait for something, use wait_event().
>>  * If you want to use yield() to be 'nice' for others, use cond_resched().
>>  * If you still want to use yield(), do not!
>>
>> The yield() usage of UBI really looks like the "be nice for others" case,
>> so use cond_resched().
>>
>> Signed-off-by: Richard Weinberger <richard@nod.at>
>> CC: peterz@infradead.org
>
> I guess we would better sleep for a couple of hundreds of milliseconds
> instead.

So, you'd prefer a msleep_interruptible(500) instead of yield() in this case?

> The purpose was different. If we have I/O error, we hope it is a
> transient failure. E.g., the HW is temporary unavailable because of an
> internal issue. And with yield() we hoped to schedule away for longer
> time than usual and let other processes which may affect that HW go
> forward and do something.

Okay, yield() is clearly the wrong choice here.
cond_resched() is better.

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2012-05-08 10:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-08  8:26 [PATCH] UBI: Replace yield() with cond_resched() Richard Weinberger
2012-05-08  8:26 ` Richard Weinberger
2012-05-08  8:31 ` Peter Zijlstra
2012-05-08  8:31   ` Peter Zijlstra
2012-05-08  9:02 ` Artem Bityutskiy
2012-05-08  9:02   ` Artem Bityutskiy
2012-05-08 10:59   ` Richard Weinberger [this message]
2012-05-08 10:59     ` Richard Weinberger
2012-05-08 13:23     ` Artem Bityutskiy
2012-05-08 13:23       ` Artem Bityutskiy
2012-05-08 13:22       ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA8FC83.7000503@nod.at \
    --to=richard@nod.at \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.