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

Atlant Schmidt aschmidt at dekaresearch.com
Fri Jul 22 06:50:12 EDT 2011


Artem:

  Thanks! We've already tuned the Linux page cache
  to be quite a lot less bursty (for example, by
  decreasing the dirty_expire_centisecs from 3000
  (30 seconds) to 500 (5 seconds); this substantially
  removed the burstiness associated with the VFS
  (and the associated pagecache flushing tasks).

  Now, though, we assume we're up against garbage
  collection in the UBIfs so we wonder if there's
  a way to make *THAT* operation either:

    1. Less bursty (perhaps by making it run more
       often but have less work to do at each run),
       or

    2. Externally schedulable so we could cause it
       to occur when we have idle CPU time and its
       running won't affect the realtime behavior
       of the rest of our system.

  Can either of those things be done?

                            Atlant

-----Original Message-----
From: Artem Bityutskiy [mailto:dedekind1 at gmail.com]
Sent: Friday, July 22, 2011 04:34
To: Atlant Schmidt
Cc: 'linux-mtd at lists.infradead.org'
Subject: Re: Can major re-organization activities of the UBIfs be "deliberately provoked"?

On Thu, 2011-07-21 at 09:33 -0400, Atlant Schmidt wrote:
> 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.

If the bursts are probably dues to write-back which is initiated by VFS.
When UBIFS is doing write-back it needs to compress data, it may need to
do GC if there is not space.

First - check if the bursts are indeed about write-back - change the
period of write-back and see. Or type sync and see the utilization. Then
you can play with VFS knobs and lessen the write-back intervals
in /proc.


--
Best Regards,
Artem Bityutskiy


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