* why use a very low-efficient method to check all the uncheked inode in garbage_collect_pass
@ 2013-06-28 14:48 zhengjun
2013-07-18 7:11 ` Abhijit Lamsoge
0 siblings, 1 reply; 2+ messages in thread
From: zhengjun @ 2013-06-28 14:48 UTC (permalink / raw)
To: linux-mtd
I encountered a problem with my linux system(uses jffs2 file system)
After scan all inode on the flash, a background thread ( garbage_collect_thread) is start。 Before collecting,
it begins with checking crc of all inodes in inode_cache_list. But unluckly the checking work cost all most 3
minutes。It costs the 98% of all cpu resource.
I found that the time is wasted on finding out the valid inode_cache with specified inode id (c->checked_ino)。
checked_ino is counted from zero to c->higest_ino。
In my system, there are 3000 files,but with higest_ino reached to 27262976。
(Because the old file is replaced by new file, by first delete then copy)。
So the most of time, jffs2_get_inode_cache can not find a valid inode with c->checked_ino。
So the useless search works wastes a lot of time.
why?
why use a increased index to find each indoe_cache in inode_cache_list, but you never know which index is the valide ino.
The indode_cache_list is a hash table.
why not use a deep-first-search method to get each inode in hash table?
Just remember next valid ino in c->checked_ino.
Now I designed a new search method。 It works much more efficiently.
Could you optimize these code for better work? Thanks!
jffs2_garbage_collect_pass()
{
....
if( c->unchecked_size )
{
ic = jffs2_get_inode_cache_next( c, & c->checked_ino ); // new search method
if( !ic )
{
BUG();
}
}
....
}
struct jffs2_inode_cache * jffs2_get_inode_cache_next( struct jffs2_sb_info * c, uint32_t * ino )
{
struct jffs2_inode_cache * ret;
uint32_t curIno;
uint32_t ihash;
curIno = *ino;
ihash = curino % 128;
ret = c->inode_cache_list[ihash];
while( NULL != ret )
{
if( ret->ino >= curInfo )
{
goto findinode;
}
ret = ret ->next;
}
for( ihash = ihash + 1; ihash < 128; ihash ++ )
{
if( NULL != ( ret = c->inode_cache_list[ihash] ) )
goto findinode;
}
return NULL;
findinode:
if( ret->next )
{
*ino = ret->next->ino;
} else
{
*ino = ihash + 1;
}
return ret;
}
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: why use a very low-efficient method to check all the uncheked inode in garbage_collect_pass
2013-06-28 14:48 why use a very low-efficient method to check all the uncheked inode in garbage_collect_pass zhengjun
@ 2013-07-18 7:11 ` Abhijit Lamsoge
0 siblings, 0 replies; 2+ messages in thread
From: Abhijit Lamsoge @ 2013-07-18 7:11 UTC (permalink / raw)
To: linux-mtd
unsubscribe linux-mtd
On Fri, Jun 28, 2013 at 8:18 PM, zhengjun <zhengun23@126.com> wrote:
> I encountered a problem with my linux system(uses jffs2 file system)
> After scan all inode on the flash, a background thread ( garbage_collect_thread) is start。 Before collecting,
> it begins with checking crc of all inodes in inode_cache_list. But unluckly the checking work cost all most 3
> minutes。It costs the 98% of all cpu resource.
> I found that the time is wasted on finding out the valid inode_cache with specified inode id (c->checked_ino)。
> checked_ino is counted from zero to c->higest_ino。
> In my system, there are 3000 files,but with higest_ino reached to 27262976。
> (Because the old file is replaced by new file, by first delete then copy)。
> So the most of time, jffs2_get_inode_cache can not find a valid inode with c->checked_ino。
> So the useless search works wastes a lot of time.
> why?
> why use a increased index to find each indoe_cache in inode_cache_list, but you never know which index is the valide ino.
> The indode_cache_list is a hash table.
> why not use a deep-first-search method to get each inode in hash table?
> Just remember next valid ino in c->checked_ino.
>
> Now I designed a new search method。 It works much more efficiently.
>
> Could you optimize these code for better work? Thanks!
>
> jffs2_garbage_collect_pass()
> {
> ....
> if( c->unchecked_size )
> {
> ic = jffs2_get_inode_cache_next( c, & c->checked_ino ); // new search method
>
> if( !ic )
> {
> BUG();
> }
> }
> ....
> }
>
> struct jffs2_inode_cache * jffs2_get_inode_cache_next( struct jffs2_sb_info * c, uint32_t * ino )
> {
> struct jffs2_inode_cache * ret;
> uint32_t curIno;
> uint32_t ihash;
>
> curIno = *ino;
> ihash = curino % 128;
>
> ret = c->inode_cache_list[ihash];
>
> while( NULL != ret )
> {
> if( ret->ino >= curInfo )
> {
> goto findinode;
> }
> ret = ret ->next;
> }
> for( ihash = ihash + 1; ihash < 128; ihash ++ )
> {
> if( NULL != ( ret = c->inode_cache_list[ihash] ) )
> goto findinode;
> }
> return NULL;
> findinode:
> if( ret->next )
> {
> *ino = ret->next->ino;
> } else
> {
> *ino = ihash + 1;
> }
> return ret;
> }
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-07-18 7:11 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-28 14:48 why use a very low-efficient method to check all the uncheked inode in garbage_collect_pass zhengjun
2013-07-18 7:11 ` Abhijit Lamsoge
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.