public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Alexey, Korolev" <alexey.korolev@intel.com>
To: Nicolas Pitre <nico@cam.org>
Cc: David Woodhouse <dwmw2@infradead.org>, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] cfi: Fixup of write errors on XIP
Date: Thu, 30 Mar 2006 17:27:38 +0400	[thread overview]
Message-ID: <442BDCCA.6000408@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603291745000.14923@localhost.localdomain>

Nicolas

Thank you very much for assistance.

>>I think both solutions, although they fix this particular problem, are 
>>not addressing the fundamental issue which is that the current code 
>>structure to cope with XIP and non-XIP is becoming a total mess.  In 
>>fact the whole timeout/error handling should be factored out of every 
>>functions into a sincle subfunction, actually one for XIP and one for 
>>non-XIP.  This way the XIP case would not have to care about chip 
>>state changing since that cannot happen, and the timeout treshold 
>>would be more accurately computed as well.
>>    
>>
It's correct. I had to spent some time to find out the solution which 
doesn't break anything and doesn't change the architecure.
IMO your fix is much better than I expected.

>Please find attached a patch for what I mean.
>
>Could you test it and confirm the problem is actually gone?
>  
>
This code definetely will not cause the write error issue on XIP.
For just a case I made tests. No write errors were faced after 3 hours 
of testing.

I have one comment to the patch:

>+
>+	if (!z) {
>+		if (!--(*chip_op_time))
>+			*chip_op_time = 1;
>+	} else if (z > 1)
>+		*chip_op_time += z/2;
>
This change may negativelly affect on write performance in case of SND 
kernel configuration.
The process of write timeout increasing if faster than process of write 
timeout decreasing.
If we consider write time as a random value with mean = 
chip->buffer_write_time and unknown variance.
It means that average buffer write timeout will be greater than 
necessary timeout.
For example: consider the process : 1 write: average time + 10us; 2 
write: average time - 10us; 3 write average time time + 10us etc.

To check it I made additional performance test on station with P30 chip.
MTD RAW write performance degradation was 3% in comaprision to kernel 
witout the patch.
I think it would be better to left    *chip_op_time ++  as it was before.

Thanks,
Alexey

  reply	other threads:[~2006-03-30 13:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-01 18:20 [PATCH] cfi: Fixup of write errors on XIP Korolev, Alexey
2006-03-02 15:36 ` Nicolas Pitre
2006-03-02 16:35   ` Alexey, Korolev
2006-03-10 16:36     ` Nicolas Pitre
2006-03-21 14:26       ` Alexey, Korolev
2006-03-21 15:10         ` Nicolas Pitre
2006-03-28 14:09           ` Alexey, Korolev
2006-03-29 16:34             ` Nicolas Pitre
2006-03-29 16:44               ` Nicolas Pitre
2006-03-30  2:54               ` Nicolas Pitre
2006-03-30 13:27                 ` Alexey, Korolev [this message]
2006-03-30 14:38                   ` Nicolas Pitre
  -- strict thread matches above, loose matches on Subject: below --
2006-03-02 10:18 Korolev, Alexey
2006-02-22 18:17 Korolev, Alexey
2006-03-01 17:48 ` Alexey, Korolev

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=442BDCCA.6000408@intel.com \
    --to=alexey.korolev@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nico@cam.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox