From: "Artem B. Bityutskiy" <dedekind@yandex.ru>
To: Ferenc Havasi <havasi@inf.u-szeged.hu>
Cc: Andrew Lunn <andrew@lunn.ch>, Linux MTD <linux-mtd@lists.infradead.org>
Subject: Re: Another compiler error: sumtool.c
Date: Thu, 22 Sep 2005 13:50:22 +0400 [thread overview]
Message-ID: <43327E5E.5090701@yandex.ru> (raw)
In-Reply-To: <43327C07.6020506@inf.u-szeged.hu>
Dear Ferenc,
Ferenc Havasi wrote:
>>EBS makes mount really faster. But then the JFFS2 checker is working,
>>and in case of NOR+EBS it will work longer and eat more CPU. JFFS2
>>writers are blocked while the checker is working, so it may slow down
>>the boot process. That's the theory, experiments are needed.
>
> Artem, I think you have a little bit negative attitude against
> summary/EBS. :) You are right, we should write docs for summary, and we
> will do it soon.
No, beleave me! :-) I am actually fond of it as it improves JFFS2
scalability. I'm just being strict.
> Just for information: EBS was mainly designed for NAND, because JFFS2
> was designed for NOR, and produces very very slow mounting on big NAND
> chips. The idea is simple, and it seems to cause mount speed up at NOR,
> too. We've got many positive feedbacks. The price of the using EBS at
> NOR is to disable the obsolating method of NOR and apply the one used on
> NAND. I don't think it cause too much CPU penalty in normal usage, at
> least nobody complained of it.
May be you did not notice, I said EBS *may* be slow for *small* NOR
flashes. This means it should be OK for large ones. How small - no idea.
Just off the top of my head - may be 8-16 MB. I explained why I think so
- if you don't agree - complain please :-). Don't take any offense
please :-)
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
prev parent reply other threads:[~2005-09-22 9:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 21:13 Another compiler error: sumtool.c Andrew Lunn
2005-09-22 6:20 ` Artem B. Bityutskiy
2005-09-22 6:41 ` Andrew Lunn
2005-09-22 6:50 ` Artem B. Bityutskiy
2005-09-22 9:40 ` Ferenc Havasi
2005-09-22 9:50 ` Artem B. Bityutskiy [this message]
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=43327E5E.5090701@yandex.ru \
--to=dedekind@yandex.ru \
--cc=andrew@lunn.ch \
--cc=havasi@inf.u-szeged.hu \
--cc=linux-mtd@lists.infradead.org \
/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.