CLEANMARKER question

CLEANMARKER question

[Joakim Tjernlund]

>joakim.tjernlund@lumentis.se said:
>> OK, I suspected that much. So after a CLEANMARKER there can be a
>> NODETYPE_INODE or a NODETYPE_DIRENT?
>
>Or indeed any other type of node, when new ones get invented - yes.
>
>> Why do you do 2 scan_empty() calls in scan_eraseblock() ?
>
>Consider it loop unrolling.
>
>> Well, sofar I have only identified one improvement. One could add an
>> isempty() function in the mtd layer. That would improve scaning for
>> empy flash so that you dont have to mtd->read() into a buffer and then
>> check the buffer for 0xffffffff. How does that sound?
>
>Sounds ugly, but could be effective. Want to benchmark it to see if it's
>really worth it?

I did a very ugly hack to see if there was a big difference.
on my FS(¨~62 MB flash partition, 31% in use) it took
12.2 sec to mount with my ugly hack and it
tackes 13.3 sec without the ugly hack.

I guess it's not worth it.

>
>
>If there's a way to safely avoid having to check all the node CRCs on
>mount, that would also help.

Yes, I once commented out all crc checking in scan just to see what happened
and there was a difference, but I can not remeber how much.

>
>The most useful thing to do, though, would probably be to implement
>checkpointing.
I have seen alot of posts about it but I have no idea on how to proceed
with this.

Would checkpointing  still speed up mount when power is cut and then
restored?

Re: CLEANMARKER question

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
> I have seen alot of posts about it but I have no idea on how to
> proceed with this.

The basic idea is to make it nice and quick for the FS code to reproduce 
its internal data (the jffs2_raw_node_ref lists and clean/dirty sizes) on 
mount without having to work it all out from scratch. Look at what the 
mount code does, and see how much could be avoided - then work out 
precisely what needs to go into the checkpoint - it'll probably end up 
being a tradeoff between remount speed and the size taken by the checkpoint 
nodes.

I wonder if we could get away with writing a node at the _end_ of each
eraseblock, just listing the start addresses of the nodes contained within
that block?

> Would checkpointing  still speed up mount when power is cut and then
> restored? 

If you write a checkpoint only on a clean unmount, then no.
If you do it periodically during normal operation. then yes.

--
dwmw2

Cache mappings and invalidate

[Joakim Tjernlund]

Hi all

I am trying to make copy_from use cahced memory by assignig 
map_priv_2 = (unsigned long)__ioremap(flash_addr, flash_size, 0);
and then change copy_from routine to:
+#ifndef NO_CACHE
+       memcpy_fromio(to, (void *)(map->map_priv_2 + from), len);
+#else
        memcpy_fromio(to, (void *)(map->map_priv_1 + from), len);
+#endif

There are no cache invalidations in my map file, instead I have 
added invalidate_dcache_range() calls to drivers/mtd/chips/cfi_cmdset_0001.c(see below)
in do_write_oneword(), do_write_buffer() and do_erase_oneblock(). Note that
this is just a quick hack to try out my theory. Does this look sane or should I use
another invalidate_dcache_range() and/or place the invalidate calls somewhere else?

I am not using burst reads yet, that will come later once i have gotten the cached mapping
to work.
 
       Joakim



--- drivers/mtd/chips/cfi_cmdset_0001.c 2001/10/25 12:11:10     1.3
+++ drivers/mtd/chips/cfi_cmdset_0001.c 2001/11/12 12:02:33
@@ -502,6 +502,10 @@
        cfi_udelay(chip->word_write_time);
        spin_lock_bh(chip->mutex);

+#ifndef NO_CACHE
+       invalidate_dcache_range(map->map_priv_2 + adr, map->map_priv_2 + adr + 4); /* on a 32 bit bus */
+#endif
+
        timeo = jiffies + (HZ/2);
        z = 0;
        for (;;) {
@@ -691,7 +695,7 @@
        wbufsize = CFIDEV_INTERLEAVE << cfi->cfiq->MaxBufWriteSize;
        adr += chip->start;
        cmd_adr = adr & ~(wbufsize-1);
-
+
        /* Let's determine this according to the interleave only once */
        status_OK = CMD(0x80);
 
@@ -790,6 +794,10 @@
        cfi_udelay(chip->buffer_write_time);
        spin_lock_bh(chip->mutex);
 
+#ifndef NO_CACHE
+       invalidate_dcache_range(map->map_priv_2 + adr, map->map_priv_2 + adr + len);
+#endif
+
        timeo = jiffies + (HZ/2);
        z = 0;
        for (;;) {
@@ -994,6 +1002,10 @@
        spin_unlock_bh(chip->mutex);
        schedule_timeout(HZ);
        spin_lock_bh(chip->mutex);
+
+#ifndef NO_CACHE
+       invalidate_dcache_range(map->map_priv_2 + adr, map->map_priv_2 + adr + 0x40000);
/* 0x40000 is my erase size */
+#endif
 
        /* FIXME. Use a timer to check this, and return immediately. */
        /* Once the state machine's known to be working I'll do that */

CLEANMARKER question

[Joakim Tjernlund]

Hi all

I am trying to understand the scan procedure in JFFS2 since I want to improve 
the speed in mounting a JFFS2 FS.

I have problems to understand the CLEANMARKER concept. Can a flash erase 
sector which has a CLEANMARKER in the beginning contain any data or can one 
assume that the rest of the erase sector is erased?

  Jocke

Re: CLEANMARKER question

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
> I have problems to understand the CLEANMARKER concept. Can a flash
> erase  sector which has a CLEANMARKER in the beginning contain any
> data or can one  assume that the rest of the erase sector is erased?

Yes, it can contain data. The CLEANMARKER is there just to show that the 
erase completed successfully. It's not erased before the block is actually 
filled with data.

What are your plans for improving the mount speed?

--
dwmw2

RE: CLEANMARKER question

[Joakim Tjernlund]

> From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
> Woodhouse
> Joakim.Tjernlund@lumentis.se said:
> > I have problems to understand the CLEANMARKER concept. Can a flash
> > erase  sector which has a CLEANMARKER in the beginning contain any
> > data or can one  assume that the rest of the erase sector is erased?
> 
> Yes, it can contain data. The CLEANMARKER is there just to show that the 
> erase completed successfully. It's not erased before the block is actually 
> filled with data.
OK, I suspected that much. So after a CLEANMARKER there can be a NODETYPE_INODE or
a NODETYPE_DIRENT?

Why do you do 2 scan_empty() calls in scan_eraseblock() ?

> 
> What are your plans for improving the mount speed?
Well, sofar I have only identified one improvement. One could add an isempty() function
in the mtd layer. That would improve scaning for empy flash so that you dont
have to mtd->read() into a buffer and then check the buffer for 0xffffffff. How
does that sound?

Re: CLEANMARKER question

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> OK, I suspected that much. So after a CLEANMARKER there can be a
> NODETYPE_INODE or a NODETYPE_DIRENT?

Or indeed any other type of node, when new ones get invented - yes.

> Why do you do 2 scan_empty() calls in scan_eraseblock() ?

Consider it loop unrolling. 

> Well, sofar I have only identified one improvement. One could add an 
> isempty() function in the mtd layer. That would improve scaning for 
> empy flash so that you dont have to mtd->read() into a buffer and then 
> check the buffer for 0xffffffff. How does that sound? 

Sounds ugly, but could be effective. Want to benchmark it to see if it's 
really worth it?

If there's a way to safely avoid having to check all the node CRCs on 
mount, that would also help.

The most useful thing to do, though, would probably be to implement 
checkpointing.

--
dwmw2