All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
To: Richard Weinberger <richard@nod.at>,
	Brian Norris <computersforpeace@gmail.com>
Cc: <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] ubi: do not re-read the data already read out in retry
Date: Mon, 24 Aug 2015 15:04:02 +0800	[thread overview]
Message-ID: <55DAC1E2.2040700@cn.fujitsu.com> (raw)
In-Reply-To: <55DABDBB.4080404@nod.at>

On 08/24/2015 02:46 PM, Richard Weinberger wrote:
> Am 24.08.2015 um 03:05 schrieb Dongsheng Yang:
>> On 08/21/2015 05:17 PM, Richard Weinberger wrote:
>>> Am 21.08.2015 um 09:59 schrieb Dongsheng Yang:
>>>> In ubi_io_read(), we will retry if current reading failed
>>>> to read all data we wanted. But we are doing a full re-do
>>>> in the re-try path. Actually, we can skip the data which
>>>> we have already read out in the last reading.
>>>>
>>>> Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
>>>> ---
>>>>    drivers/mtd/ubi/io.c | 19 +++++++++++++------
>>>>    1 file changed, 13 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
>>>> index 5bbd1f0..a3ac643 100644
>>>> --- a/drivers/mtd/ubi/io.c
>>>> +++ b/drivers/mtd/ubi/io.c
>>>> @@ -127,7 +127,7 @@ int ubi_io_read(const struct ubi_device *ubi, void *buf, int pnum, int offset,
>>>>            int len)
>>>>    {
>>>>        int err, retries = 0;
>>>> -    size_t read;
>>>> +    size_t read, already_read = 0;
>>>>        loff_t addr;
>>>>
>>>>        dbg_io("read %d bytes from PEB %d:%d", len, pnum, offset);
>>>> @@ -165,6 +165,7 @@ int ubi_io_read(const struct ubi_device *ubi, void *buf, int pnum, int offset,
>>>>        addr = (loff_t)pnum * ubi->peb_size + offset;
>>>>    retry:
>>>>        err = mtd_read(ubi->mtd, addr, len, &read, buf);
>>>> +    already_read += read;
>>>
>>> Hmm, this change makes me nervous.
>>
>> Ha, yes, understandable.
>>>
>>> Brian, does MTD core guarantee that upon an erroneous mtd_read() the number of "read" bytes
>>> in "buf" are valid?
>>>
>>> So, my fear is that this change will introduce new regressions (due faulty MTD drivers, etc..)
>>> without a real gain.
>>
>> I would say "big gain" rather than "real gain". Consider this case, if
>> you are going to read 4M from driver but it failed at the last byte
>> twice. When we success on the third retry, we have read out 4*3=12M for
>> 4M data user requested. That tripled the latency.
>
> How do you hit this case?
> What error is mtd_read() returning?
>
> I had the feeling that this is more a theoretical fix.

Yes, so I agreed that both of us would feel nervous about it.
I did not hit this kind of case in practise, but tested it with
some hacked code in mtdram.

TBH, my customer send me this requirement and I cooked this patch
to them.I just want to send this patch to you to see would you
be interested in it. IMO, I did not find the practical usecase
for it.

So, I understand your nervous and I am okey to drop it currently.
Maybe we can come back when we found a device driver really get
a big gain from this change. :)

Thanx
Yang
>
> Thanks,
> //richard
> .
>

  reply	other threads:[~2015-08-24  7:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-21  7:59 [PATCH] ubi: do not re-read the data already read out in retry Dongsheng Yang
2015-08-21  9:17 ` Richard Weinberger
2015-08-24  1:05   ` Dongsheng Yang
2015-08-24  6:46     ` Richard Weinberger
2015-08-24  7:04       ` Dongsheng Yang [this message]
2015-08-24 16:59         ` Brian Norris
2015-08-25  0:34           ` Dongsheng Yang
2015-08-24 16:50     ` Brian Norris

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=55DAC1E2.2040700@cn.fujitsu.com \
    --to=yangds.fnst@cn.fujitsu.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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.