From: Richard Weinberger <richard@nod.at>
To: Wang Fangpeng <wangfangpeng1@huawei.com>,
linux-mtd@lists.infradead.org, dedekind1@gmail.com
Subject: Re: Question: background GC on UBIFS
Date: Thu, 31 Mar 2016 10:53:34 +0200 [thread overview]
Message-ID: <56FCE58E.3060200@nod.at> (raw)
In-Reply-To: <56FCC2E6.5020206@huawei.com>
Am 31.03.2016 um 08:25 schrieb Wang Fangpeng:
> Hi, folks,
>
> We did some performance test of writing data to a ubifs volume by dd. The block
> size of dd is 1MB.
>
> When the volume has more than 20% free space, the speed of writing is about
> 1.4MB/s ~ 1.2MB/s.
>
> However, when the free space is less and less, the speed decreases to about
> 83KB/s. We think the overhead is caused by GC, since GC tries to find a free
> space and move valid data to another place to get a free block.
>
> Although we already have a kthread to collect freeable blocks, it doesn't
> touch blocks which have both valid and invalid nodes. My question is why don't
> we do such consolidation/defragmentation periodicly, so that the overhead
> could be decreased when there is not enough free space?
AFAIK UBIFS does this on demand to be friendly to the flash.
Otherwise it would move blocks around for nothing (if there is no writer).
Doing it periodically is doable but how often and when? Only when the system
is completely idle?
I'm not sure if there will be a huge performance gain. Basically you shift the
IO load to another location.
But you can give it a try. Add a new debugfs file to trigger an aggressive GC run.
Currently GC tries to produce as much space as we budget. You can change GC to
produce as much space as possible.
Thanks,
//richard
next prev parent reply other threads:[~2016-03-31 8:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 6:25 Question: background GC on UBIFS Wang Fangpeng
2016-03-31 8:53 ` Richard Weinberger [this message]
2016-03-31 9:50 ` Artem Bityutskiy
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=56FCE58E.3060200@nod.at \
--to=richard@nod.at \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=wangfangpeng1@huawei.com \
/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.