Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Under Powercut Testing] os/fs/driver/mtd: Read optimization when CRC and Journaling are enabled #6004

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

gSahitya-samsung
Copy link
Contributor

@gSahitya-samsung gSahitya-samsung commented Dec 7, 2023

  • When CRC and Journaling are both enabled, CRC verification of written data is done by reading it back immediately after writing.
  • Hence, we do not need to repeat this verification at the time of reading again.

os/fs/driver/mtd/smart.c Outdated Show resolved Hide resolved
os/fs/driver/mtd/smart.c Outdated Show resolved Hide resolved
os/fs/driver/mtd/smart.c Outdated Show resolved Hide resolved
os/fs/driver/mtd/smart.c Outdated Show resolved Hide resolved
@amogh-samsung
Copy link
Contributor

amogh-samsung commented Dec 7, 2023

Test pseudocode: -

for i iterations
{
    for n files
    {
        create(file)
        for t times
        {
            open(file)
            seek(END)
            write(buffer[bufsize])
            close(file)
        }
    }
}

  Byte Reads Block Reads Total Read Bytes
Before this PR 29,367 8,620 22,36,087
After this PR 7,17,100 4,613 1897925.55
    % Improvement = 15.123

The improvements may vary in different configuration settings and testcases.

os/fs/driver/mtd/smart.c Outdated Show resolved Hide resolved
os/fs/driver/mtd/smart.c Outdated Show resolved Hide resolved
os/fs/driver/mtd/smart.c Outdated Show resolved Hide resolved
os/fs/driver/mtd/smart.c Outdated Show resolved Hide resolved
@gSahitya-samsung gSahitya-samsung force-pushed the read_optimization branch 2 times, most recently from 6d903d6 to edf5974 Compare December 7, 2023 15:34
Copy link
Contributor

@Taejun-Kwon Taejun-Kwon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion, we should compare 1 time of bread & 2 times of read, in otherwords, read count & read size should be checked.
please verify this with tp1x, tp2x, 8730.
I think read count is more important factor because every time it should lock flash & wait for dma interrupt, for most of case.

#endif
#endif /* defined(CONFIG_MTD_SMART_ENABLE_CRC) && !defined(CONFIG_MTD_SMART_JOURNALING) */

errout:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

useless errout

@amogh-samsung
Copy link
Contributor

In my opinion, we should compare 1 time of bread & 2 times of read, in otherwords, read count & read size should be checked. please verify this with tp1x, tp2x, 8730. I think read count is more important factor because every time it should lock flash & wait for dma interrupt, for most of case.

We want to check that total read calls to flash are increased/decreased/constant? We should check this at a lower hardware level.
Is that right @Taejun-Kwon ? Total number of read bytes is definitely decreased.
Please keep a check on this @gSahitya-samsung

We should do this for our most commercialized boards - 8721csm, 8730e and mt87686_hdk

@amogh-samsung
Copy link
Contributor

@gSahitya-samsung
Please also repeat the test with all intermediate logs disabled and with timing enabled.
Lets see if more number of byte reads leads to more time consumption as TJ suggested.

We have to evaluate
Lesser total bytes read VS More total read calls to hardware and time/energy consumed

@Taejun-Kwon
Copy link
Contributor

In my opinion, we should compare 1 time of bread & 2 times of read, in otherwords, read count & read size should be checked. please verify this with tp1x, tp2x, 8730. I think read count is more important factor because every time it should lock flash & wait for dma interrupt, for most of case.

We want to check that total read calls to flash are increased/decreased/constant? We should check this at a lower hardware level. Is that right @Taejun-Kwon ? Total number of read bytes is definitely decreased. Please keep a check on this @gSahitya-samsung

We should do this for our most commercialized boards - 8721csm, 8730e and mt87686_hdk

I mean count of read will affect to performance more, because flow of read is...

External flash (ext flash of tp2x need to be tested)

  1. Lock flash
  2. SPI Lock
  3. send data through the spi
  4. read data through the spi
  5. SPI unlick
  6. Flash unlock

internal flash

  1. Lock Flash
  2. Copy data from flash
  3. Unlock Flash


ret = MTD_BREAD(dev->mtd, physsector * dev->mtdBlksPerSector, dev->mtdBlksPerSector, (FAR uint8_t *)dev->rwbuffer);
if (ret != dev->mtdBlksPerSector) {
fdbg("Error reading phys sector %d\n", physsector);
return -EIO;
ret = -EIO;
goto errout;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no cleanup code at errout. So i think we can directly return from here.

* However, if Journaling is enabled, written data is read back and verified with CRC,
* so we can skip this step.
*/
/* If journaling is disabled, data is not read back and verified at the time of writing itself. Hence we need to read the entire sector into RAM to validate CRC. */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pls add a tab at the beginning for this comment and split it into two lines.

When CRC and Journaling are both enabled, CRC verification of written data is done by reading it back immediately after writing.
Hence, we do not need to repeat this verification at the time of reading again.

Co-authored-by: Amogh Hassija <a.hassija@samsung.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants