Can major re-organization activities of the UBIfs be "deliberately provoked"?

Atlant Schmidt aschmidt at dekaresearch.com
Thu Jul 21 09:33:31 EDT 2011


Folks:

  We're using the UBIfs with our realtime equipment. We've
  noticed a behavior where, every so often, the flush-ubifs
  thread demands very, very large amounts of CPU time, blocking
  all of our other processes that use the Linux time-sliced
  scheduler. These bursts come at arbitrary intervals but
  commonly last ten to fifteen seconds.

  Naturally, these bursts come at exceedingly inconvenient
  times ;-).

  I *ASSUME* these bursts occur when the UBI file system has
  decided that it has to do some major Flash housekeeping;
  these bursts are associated with our application doing a
  lot of writing but *ARE NOT* associated with the display
  of any UBI/MTD error messages. (If my assumption is wrong,
  please feel free to correct me!)

  So three questions:

    1. Has this bursty behavior changed for the better
       in more-recent versions of the MTD/UBI/UBIfs code?
       (We're probably running pretty old versions of each.)

    2. Are there any tuning parameters that would let us
       spread this work out more smoothly (that is, in a
       less-bursty fashion)?

    3. Are there any APIs that would let us deliberately
       provoke this work at times that would be more-convenient
       for the rest of our application (such as when we're
       booting up or shutting down)?

                            Atlant


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.



More information about the linux-mtd mailing list