Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
2009/6/21 Pavel Machek :
>
>> >> 1. Disk-based filesystems such as ext2/ext3 were designed for optimum
>> >> performance on spinning disk media, so they implement features such
>> >> as block groups, which attempts to group inode data into a contiguous
>> >> set of data blocks to minimize disk seeking when accessing files. For
>> >> RAM there is no such concern; a file's data blocks can be scattered
>> >> throughout the media with no access speed penalty at all. So block
>> >> groups in a filesystem mounted over RAM just adds unnecessary
>> >> complexity. A better approach is to use a filesystem specifically
>> >> tailored to RAM media which does away with these disk-based features.
>> >> This increases the efficient use of space on the media, i.e. more
>> >> space is dedicated to actual file data storage and less to meta-data
>> >> needed to maintain that file data.
>> >
>> > So... what is the performance difference between ext2 and your new
>> > filesystem?
>> >
>>
>> About the "space" you can read a detailed documentation on the site:
>>
>> http://pramfs.sourceforge.net/pramfs-spec.html
>
> I do not see any numbers there. Do you think you can save significant
> memory when storing for example kernel source trees?
There aren't benchmark, but I pointed it out because if you know ext2
you can do a comparison.
>
>> In addition I can do an example of "compact" information: ext2 uses
>> directory entry objects ("dentries") to associate file names to
>> inodes,
>
> I'm not sure that on-disk directory entry == dentry.
>
>> and these dentries are located in data blocks owned by the parent
>> directory. In pramfs, directory inode's do not need to own any data
>> blocks, because all dentry information is contained within the inode's
>> themselves.
>
> How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on. However this
limitations don't limit the fs itself because you must consider the
special goal of this fs.
>
>> >From performance point of view:
>>
>> Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark
>> results to compare the performance with and without XIP in a real
>> embedded environment with bonnie++. You could use it as reference point.
>
> Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance
> better than ext2?
>
> Wait... those numbers you pointed me... claim to be as slow as
> 13MB/sec. That's very very bad. My harddrive is faster than that.
> Pavel
>
As I said I did the test in a real embedded environment so to have
comparable result you should use the same environmente with the same
tools, with the same workload and so on.
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] Pramfs: Include files
2009/6/21 Arnd Bergmann : > On Sunday 21 June 2009, Marco wrote: >> I was thinking about your comment and I think I'll use __kernel_off_t >> for the exported headers. I know that it will differ between 32 and 64 >> bit architectures, but for this kind of fs there isn't any compatibility >> problem at layout level. You cannot remove a chip of RAM from a board >> 32bit little endian and attach it to a board with a cpu 64bit big >> endian, the memory isn't a disk. Indeed, I see that tmpfs uses simply >> "unsigned long" in the exported header file without any problems to >> little or big endian. > > It's still a problem. You might be creating a file system image > for an embedded board with a different endianess. It's not possible to create an "image" with pramfs, it's like tmpfs. > Or even on the same machine, you could be looking at the file system contents > with a 32 bit process running on a 64 bit kernel. > > Arnd <>< > Yes, indeed the most important thing is to be sure that a 64bit kernel works well. I'll try to test it in this environment. If there are "64bit guys" to help me to test it, it'd be great. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] MMC Agressive clocking framework v4
This patch modified the MMC core code to optionally call the
set_ios() operation on the driver with the clock frequency set
to 0 to gate the hardware block clock (and thus the MCI clock)
for an MMC host controller after a grace period of at least 8
MCLK cycles. It is inspired by existing clock gating code found
in the OMAP and Atmel drivers and brings this up to the host
abstraction. Gating is performed before and after any MMC
request.
It exemplifies by implementing this for the MMCI/PL180 MMC/SD
host controller, but it should be simple to switch OMAP and
Atmel over to using this instead.
Signed-off-by: Linus Walleij
ChangeLog v3->v4:
Fixed a single spelling error.
---
drivers/mmc/core/Kconfig | 11 +++
drivers/mmc/core/core.c| 35 +
drivers/mmc/core/core.h|2 +
drivers/mmc/core/debugfs.c | 10 ++-
drivers/mmc/core/host.c| 165 +++-
drivers/mmc/core/host.h|3 +
include/linux/mmc/host.h |9 +++
7 files changed, 232 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index ab37a6d..5372fc9 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -14,3 +14,14 @@ config MMC_UNSAFE_RESUME
This option is usually just for embedded systems which use
a MMC/SD card for rootfs. Most people should say N here.
+config MMC_CLKGATE
+ bool "MMC host clock gaing (EXPERIMENTAL)"
+ depends on EXPERIMENTAL
+ help
+ This will attempt to agressively gate the clock to the MMC host,
+ which typically also will gate the MCI clock to the card. This
+ is done to save power due to gating off the logic and bus noise
+ when MMC is not in use. Your host driver has to support this in
+ order for it to be of any use.
+
+ If unsure, say N.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2649117..e9093b6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -113,6 +113,8 @@ void mmc_request_done(struct mmc_host *host, struct
mmc_request *mrq)
if (mrq->done)
mrq->done(mrq);
+
+ mmc_clk_disable(host);
}
}
@@ -173,6 +175,7 @@ mmc_start_request(struct mmc_host *host, struct mmc_request
*mrq)
mrq->stop->mrq = mrq;
}
}
+ mmc_clk_enable(host);
host->ops->request(host, mrq);
}
@@ -447,6 +450,38 @@ void mmc_set_clock(struct mmc_host *host, unsigned int hz)
mmc_set_ios(host);
}
+#ifdef CONFIG_MMC_CLKGATE
+/*
+ * This gates the clock by setting it to 0 Hz.
+ */
+void mmc_gate_clock(struct mmc_host *host)
+{
+ host->clk_old = host->ios.clock;
+ host->ios.clock = 0;
+ mmc_set_ios(host);
+}
+
+/*
+ * This restores the clock from gating by using the cached
+ * clock value.
+ */
+void mmc_ungate_clock(struct mmc_host *host)
+{
+ /*
+* We should previously have gated the clock, so the clock
+* shall be 0 here!
+* The clock may however be 0 during intialization,
+* when some request operations are performed before setting
+* the frequency. When ungate is requested in that situation
+* we just ignore the call.
+*/
+ if (host->clk_old) {
+ BUG_ON(host->ios.clock);
+ mmc_set_clock(host, host->clk_old);
+ }
+}
+#endif
+
/*
* Change the bus mode (open drain/push-pull) of a host.
*/
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index c819eff..ee27f81 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -27,6 +27,8 @@ void mmc_detach_bus(struct mmc_host *host);
void mmc_set_chip_select(struct mmc_host *host, int mode);
void mmc_set_clock(struct mmc_host *host, unsigned int hz);
+void mmc_gate_clock(struct mmc_host *host);
+void mmc_ungate_clock(struct mmc_host *host);
void mmc_set_bus_mode(struct mmc_host *host, unsigned int mode);
void mmc_set_bus_width(struct mmc_host *host, unsigned int width);
u32 mmc_select_voltage(struct mmc_host *host, u32 ocr);
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 610dbd1..1a969bd 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -149,11 +149,17 @@ void mmc_add_host_debugfs(struct mmc_host *host)
host->debugfs_root = root;
if (!debugfs_create_file("ios", S_IRUSR, root, host, &mmc_ios_fops))
- goto err_ios;
+ goto err_remove_files;
+
+#ifdef CONFIG_MMC_CLKGATE
+ if (!debugfs_create_u32("clk_delay", (S_IRUSR | S_IWUSR),
+ root, &host->clk_delay))
+ goto err_remove_files;
+#endif
return;
-err_ios:
+err_remove_files:
debugfs_remove_recursive(root);
host->debugfs_root = NULL;
err_root:
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 5e945e6..792bbfe 100644
-
[PATCH 2/2] Modify MMCI/PL180 to handle agressive clocking v4
This adds a few clk_enable()/clk_disable() calls to the MMCI
driver so as to handle an set_ios() request with clock
frequency set to 0 as an instruction to gate the block clock.
This also breaks out the clock setting code into its own
function to simplify the set_ios() function a bit.
Signed-off-by: Linus Walleij
---
drivers/mmc/host/mmci.c | 78 ++
1 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 36875dc..d9f5c9a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -37,8 +37,34 @@
static unsigned int fmax = 515633;
+/*
+ * This must be called with host->lock held
+ */
+static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
+{
+ u32 clk = 0;
+
+ if (desired) {
+ if (desired >= host->mclk) {
+ clk = MCI_CLK_BYPASS;
+ host->cclk = host->mclk;
+ DBG(host, "MMCI: bypass clock divider, cclk = %u Hz\n",
host->cclk);
+ } else {
+ clk = host->mclk / (2 * desired) - 1;
+ if (clk >= 256)
+ clk = 255;
+ host->cclk = host->mclk / (2 * (clk + 1));
+ DBG(host, "MMCI: divide cclk to %u Hz (divide %u by
%u)\n", host->cclk, host->mclk, clk);
+ }
+ if (host->hw_designer == 0x80)
+ clk |= MCI_FCEN; /* Bug fix in ST IP block */
+ clk |= MCI_CLK_ENABLE;
+ }
+ writel(clk, host->base + MMCICLOCK);
+}
+
static void
-mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
+ mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
writel(0, host->base + MMCICOMMAND);
@@ -418,22 +444,7 @@ static void mmci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct mmci_host *host = mmc_priv(mmc);
- u32 clk = 0, pwr = 0;
-
- if (ios->clock) {
- if (ios->clock >= host->mclk) {
- clk = MCI_CLK_BYPASS;
- host->cclk = host->mclk;
- } else {
- clk = host->mclk / (2 * ios->clock) - 1;
- if (clk >= 256)
- clk = 255;
- host->cclk = host->mclk / (2 * (clk + 1));
- }
- if (host->hw_designer == 0x80)
- clk |= MCI_FCEN; /* Bug fix in ST IP block */
- clk |= MCI_CLK_ENABLE;
- }
+ u32 pwr = 0;
if (host->plat->translate_vdd)
pwr |= host->plat->translate_vdd(mmc_dev(mmc), ios->vdd);
@@ -464,12 +475,23 @@ static void mmci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
}
}
- writel(clk, host->base + MMCICLOCK);
+ spin_lock(&host->lock);
+
+ if (ios->clock == 0) {
+ clk_disable(host->clk);
+ } else {
+ clk_enable(host->clk);
+ mmci_set_clkreg(host, ios->clock);
+ }
if (host->pwr != pwr) {
host->pwr = pwr;
+ clk_enable(host->clk);
writel(pwr, host->base + MMCIPOWER);
+ clk_disable(host->clk);
}
+
+ spin_unlock(&host->lock);
}
static const struct mmc_host_ops mmci_ops = {
@@ -615,6 +637,8 @@ static int __devinit mmci_probe(struct amba_device *dev,
void *id)
host->timer.expires = jiffies + HZ;
add_timer(&host->timer);
+ /* The first IOS will turn the clock on again */
+ clk_disable(host->clk);
return 0;
irq0_free:
@@ -646,17 +670,22 @@ static int __devexit mmci_remove(struct amba_device *dev)
mmc_remove_host(mmc);
+ /* framework may have gated the block clock */
+ clk_enable(host->clk);
+
writel(0, host->base + MMCIMASK0);
writel(0, host->base + MMCIMASK1);
writel(0, host->base + MMCICOMMAND);
writel(0, host->base + MMCIDATACTRL);
+ clk_disable(host->clk);
+
free_irq(dev->irq[0], host);
free_irq(dev->irq[1], host);
iounmap(host->base);
- clk_disable(host->clk);
+
clk_put(host->clk);
mmc_free_host(mmc);
@@ -677,8 +706,11 @@ static int mmci_suspend(struct amba_device *dev,
pm_message_t state)
struct mmci_host *host = mmc_priv(mmc);
ret = mmc_suspend_host(mmc, state);
- if (ret == 0)
+ if (ret == 0) {
+ clk_enable(host->clk);
writel(0, host->base + MMCIMASK0);
+ clk_disable(host->clk);
+ }
}
return r
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
> >> 1. Disk-based filesystems such as ext2/ext3 were designed for optimum
> >>performance on spinning disk media, so they implement features such
> >>as block groups, which attempts to group inode data into a contiguous
> >>set of data blocks to minimize disk seeking when accessing files. For
> >>RAM there is no such concern; a file's data blocks can be scattered
> >>throughout the media with no access speed penalty at all. So block
> >>groups in a filesystem mounted over RAM just adds unnecessary
> >>complexity. A better approach is to use a filesystem specifically
> >>tailored to RAM media which does away with these disk-based features.
> >>This increases the efficient use of space on the media, i.e. more
> >>space is dedicated to actual file data storage and less to meta-data
> >>needed to maintain that file data.
> >
> > So... what is the performance difference between ext2 and your new
> > filesystem?
> >
>
> About the "space" you can read a detailed documentation on the site:
>
> http://pramfs.sourceforge.net/pramfs-spec.html
I do not see any numbers there. Do you think you can save significant
memory when storing for example kernel source trees?
> In addition I can do an example of "compact" information: ext2 uses
> directory entry objects ("dentries") to associate file names to
> inodes,
I'm not sure that on-disk directory entry == dentry.
> and these dentries are located in data blocks owned by the parent
> directory. In pramfs, directory inode's do not need to own any data
> blocks, because all dentry information is contained within the inode's
> themselves.
How do you handle hard-links, then?
> >From performance point of view:
>
> Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark
> results to compare the performance with and without XIP in a real
> embedded environment with bonnie++. You could use it as reference point.
Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance
better than ext2?
Wait... those numbers you pointed me... claim to be as slow as
13MB/sec. That's very very bad. My harddrive is faster than that.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MMC Agressive clocking framework v3
On Sun, 21 Jun 2009 22:05:18 +0200 Linus Walleij wrote: > 2009/6/18 Linus Walleij : > > > diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig > >(...) > > + Of unsure, say N. > > However the rest of the patch is as I intended. I'll send a V4 pronto > if you want that for the current merge window. > I'm trying to squeeze you in, but time is short so I'm afraid I can't give you any guarantees. :/ Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: [PATCH 06/14] Pramfs: Include files
On Sunday 21 June 2009, Marco wrote: > I was thinking about your comment and I think I'll use __kernel_off_t > for the exported headers. I know that it will differ between 32 and 64 > bit architectures, but for this kind of fs there isn't any compatibility > problem at layout level. You cannot remove a chip of RAM from a board > 32bit little endian and attach it to a board with a cpu 64bit big > endian, the memory isn't a disk. Indeed, I see that tmpfs uses simply > "unsigned long" in the exported header file without any problems to > little or big endian. It's still a problem. You might be creating a file system image for an embedded board with a different endianess. Or even on the same machine, you could be looking at the file system contents with a 32 bit process running on a 64 bit kernel. Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MMC Agressive clocking framework v3
2009/6/18 Linus Walleij : > diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig >(...) > + Of unsure, say N. However the rest of the patch is as I intended. I'll send a V4 pronto if you want that for the current merge window. Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Pavel Machek wrote:
>>> Why is an entire filesystem needed, instead of simply a block driver
>>> if the ramdisk driver cannot be used?
>>>
>> >From documentation:
>>
>> "A relatively straight-forward solution is to write a simple block
>> driver for the non-volatile RAM, and mount over it any disk-based
>> filesystem such as ext2/ext3, reiserfs, etc.
>>
>> But the disk-based fs over non-volatile RAM block driver approach has
>> some drawbacks:
>>
>> 1. Disk-based filesystems such as ext2/ext3 were designed for optimum
>>performance on spinning disk media, so they implement features such
>>as block groups, which attempts to group inode data into a contiguous
>>set of data blocks to minimize disk seeking when accessing files. For
>>RAM there is no such concern; a file's data blocks can be scattered
>>throughout the media with no access speed penalty at all. So block
>>groups in a filesystem mounted over RAM just adds unnecessary
>>complexity. A better approach is to use a filesystem specifically
>>tailored to RAM media which does away with these disk-based features.
>>This increases the efficient use of space on the media, i.e. more
>>space is dedicated to actual file data storage and less to meta-data
>>needed to maintain that file data.
>
> So... what is the performance difference between ext2 and your new
> filesystem?
>
About the "space" you can read a detailed documentation on the site:
http://pramfs.sourceforge.net/pramfs-spec.html
In addition I can do an example of "compact" information: ext2 uses
directory entry objects ("dentries") to associate file names to inodes,
and these dentries are located in data blocks owned by the parent
directory. In pramfs, directory inode's do not need to own any data
blocks, because all dentry information is contained within the inode's
themselves.
>From performance point of view:
Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark
results to compare the performance with and without XIP in a real
embedded environment with bonnie++. You could use it as reference point.
I hope I've answered to your question.
Regards,
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] Pramfs: Include files
Arnd Bergmann wrote:
> On Saturday 13 June 2009, Sam Ravnborg wrote:
>>> + union {
>>> + struct {
>>> + /*
>>> + * ptr to row block of 2D block pointer array,
>>> + * file block #'s 0 to (blocksize/4)^2 - 1.
>>> + */
>>> + off_t row_block;
>> It is my understanding that we shall use: __kernel_off_t
>> in exported headers.
>
> That is a correct understanding in general, however this case is
> different, because it describes an on-disk data structure,
> not a kernel to user space interface. Here, __kernel_off_t is just
> as wrong as off_t, because it will differ between 32 and 64 bit
> architectures, making the fs layout incompatible. I'd suggest
> simply defining this as __u64.
>
> Moreover, file system layout should be described in terms of
> big-endian or little-endian types (e.g. __be64 or __le64),
> together with the right accessor functions.
>
> Arnd <><
>
I was thinking about your comment and I think I'll use __kernel_off_t
for the exported headers. I know that it will differ between 32 and 64
bit architectures, but for this kind of fs there isn't any compatibility
problem at layout level. You cannot remove a chip of RAM from a board
32bit little endian and attach it to a board with a cpu 64bit big
endian, the memory isn't a disk. Indeed, I see that tmpfs uses simply
"unsigned long" in the exported header file without any problems to
little or big endian.
Regards,
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
