* Re: AMP on an SMP system
From: Michael Schnell @ 2013-08-02 12:13 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded
In-Reply-To: <20130802114225.GR3880@pengutronix.de>
On 08/02/2013 01:42 PM, Robert Schwebel wrote:
> Before hacking around (which might also lead to interesting solutions),
> I would start using a kernel with preempt-rt support and play with the
> cpu affinity:
>
> http://lxr.linux.no/#linux+v3.10.4/Documentation/kernel-parameters.txt#L1257
>
Robert !
Nice to see you here (I do own your "Embedded Linux Handbuch für
Entwickler" :-) )
Thanks for the pointer !
I do already know "preempt-rt", but I was not aware of cpu affinity.
So this might help.
In fact I need a way to do very guaranteed low latency. regarding the
high clock rate (about 1 GHz) modern ARM chips can provide, maybe
preempt-rt with the cpu affinity might be a decent way to go.
The raining questions include
- how to calculate the maximum latency that can be guaranteed ? (i.e.
does the Kernel impose any spinlocks and interrupt disables on the would
be AMP subsystem ?)
- how to assign an interrupt (e.g. a dedicated timer) to the subsystem ?
- Do the interrupts immediately call the ISR of the cpu "under
affinity" or is some additional latency imposed by the Kernel (and how
many cpu cycles at max are needed to enter the ISR) ?
Thanks,
-Michael
^ permalink raw reply
* Re: AMP on an SMP system
From: Robert Schwebel @ 2013-08-02 11:42 UTC (permalink / raw)
To: Michael Schnell; +Cc: linux-embedded
In-Reply-To: <51FB6EE1.3090708@lumino.de>
On Fri, Aug 02, 2013 at 10:33:37AM +0200, Michael Schnell wrote:
> Is there a kind of "official" way to set aside one of the available
> cores in an SMP system from the Linux OS to do deeply embedded
> extremely-low-latency stuff in a kind of single task "main loop" type
> environment ? I.e. creating a true coprocessor from an SMP hardware.
Before hacking around (which might also lead to interesting solutions),
I would start using a kernel with preempt-rt support and play with the
cpu affinity:
http://lxr.linux.no/#linux+v3.10.4/Documentation/kernel-parameters.txt#L1257
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* AMP on an SMP system
From: Michael Schnell @ 2013-08-02 8:33 UTC (permalink / raw)
To: linux-embedded
Hi Experts.
Is there a kind of "official" way to set aside one of the available
cores in an SMP system from the Linux OS to do deeply embedded
extremely-low-latency stuff in a kind of single task "main loop" type
environment ? I.e. creating a true coprocessor from an SMP hardware.
Some of the problems that come in ind here include:
- how to make the Linux initialization ignore one of the available
cores or free a core later on ?
Here I found this:
http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re46.html
So using one of the four cores for special purpose in fact is viable.
- how to have a Linux task start the free running main loop ?
- how to assign certain interrupts to that core and have ISRs run
there only dedicatedly interrupting the "main loop" and not ever being
blocked by any Linux activity ?
here I found this:
https://access.redhat.com/site/solutions/15482
In fact of course the hardware defines if/how a certain Interrupt can be
assigned to a certain CPU. How is this usually done when using ARM
Cortex A9+ cores ?
- what about MMU issues ?
- how to have a Linux application communicate with the non.-Linux
application running on the dedicated core ?
Here I found this:
http://lwn.net/Articles/464391
For example I (e.g.) would like a (now rather cheap) standard quadcore
ARM Cortex A9 processor chip and modify a Debian distribution in a way
that support this stuff.
Thanks for any pointers ?
-Michael
^ permalink raw reply
* Re: [PATCH 0/2] Squashfs: add LZ4 compression
From: Rob Landley @ 2013-07-26 22:00 UTC (permalink / raw)
To: Gu Zheng
Cc: Phillip Lougher, Phillip Lougher, linux-kernel, linux-fsdevel,
linux-embedded
In-Reply-To: <51ECCB8B.7030104@cn.fujitsu.com>
On 07/22/2013 01:04:59 AM, Gu Zheng wrote:
> On 07/22/2013 01:07 PM, Phillip Lougher wrote:
>
> > On 22 July 2013 04:05, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
> >> Hi Phillip,
> >> Have some tests been carried out to confirm that Squashfs
> really
> >> can get benefit from LZ4 compression, comparing with lzo?
> >
> > This seems to be a loaded question, in that it seems to be trying to
> > reopen the "why add lz4 when we already have lzo" debate all over
> > again. As LZ4 has been merged to mainline, this appears to be a
> > question that has already been answered.
>
> No, they are different. LZ4 can be merged to mainline, because we can
> see the benefit(faster compressing speed under the enabled unaligned
> memory access) it brings to us comparing with lzo.
> But it's hard to say that it also really can bring benefit to
> Squashfs.
A compression format was added to the kernel. Philip hooked up the code
that was already in the kernel to a filesystem that was already in the
kernel.
You consider this action controversial...
Rob
^ permalink raw reply
* Re: [PATCH 0/2] Squashfs: add LZ4 compression
From: Phillip Lougher @ 2013-07-22 13:38 UTC (permalink / raw)
To: Gu Zheng; +Cc: Phillip Lougher, linux-kernel, linux-fsdevel, linux-embedded
In-Reply-To: <51ECCB8B.7030104@cn.fujitsu.com>
On 22 July 2013 07:04, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
> On 07/22/2013 01:07 PM, Phillip Lougher wrote:
>
>> On 22 July 2013 04:05, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
>>> Hi Phillip,
>>> Have some tests been carried out to confirm that Squashfs really
>>> can get benefit from LZ4 compression, comparing with lzo?
>>
>> This seems to be a loaded question, in that it seems to be trying to
>> reopen the "why add lz4 when we already have lzo" debate all over
>> again. As LZ4 has been merged to mainline, this appears to be a
>> question that has already been answered.
>
> No, they are different. LZ4 can be merged to mainline, because we can
> see the benefit(faster compressing speed under the enabled unaligned
> memory access) it brings to us comparing with lzo.
The users of LZ4 that has been merged is for decompression of kernel
and initramfs, not compression. So far I don't see any users of the
LZ4 compression code in the kernel. So you're saying it was merged
for fast compression despite there being no users of it?
> But it's hard to say that it also really can bring benefit to Squashfs.
Prejudiced statement without any evidence, if that's your contention prove it.
>
>>
>> As far as Squashfs is concerned, I believe it is important to give
>> people the choice of using LZ4 to compress Squashfs filesystems now
>> its been mainlined. As far as expected benefits are concerned,
>> Squashfs' use in embedded systems is very similar to compressing
>> kernels and initramfs data, in that it tends to be used to compress
>> root filesystems. As such the benefits of using LZ4 in Squashfs
>> should be broadly similar to using LZ4 to compress kernels and
>> initramfs data. Ultimately it is up to people to experiment and
>> choose whatever compression is best for their systems.
>
> Yes, but the premise is that using LZ4 in Squashfs is better than lzo
> in at least one actual situation.
>
No. All it takes is for LZ4 to be better/faster at decompressing the
kernel or initramfs to make it advantageous to use LZ4 for Squashfs,
thus avoiding the overhead of another decompressor in the kernel..
>>
>> People are welcome to try the patches out and report their findings.
>
> Let's look and see other guys' feedbacks, they are more persuasive.:)
Suit yourself, maybe when you start using evidence rather than
unsubstantiated assertions, you'll be more persuasive too. So far all
I see is wind.
Phillip
>
> Regards,
> Gu
>
>>
>> Phillip
>>
>>>
>>> Thanks,
>>> Gu
>>>
>>> On 07/22/2013 10:21 AM, Phillip Lougher wrote:
>>>
>>>> Hi
>>>>
>>>> Now that LZ4 compression support is in 3.11-rc1, I have written the
>>>> following two patches for Squashfs to use it.
>>>>
>>>> Phillip Lougher (2):
>>>> Squashfs: add LZ4 compression support
>>>> Squashfs: Add LZ4 compression configuration option
>>>>
>>>> Documentation/filesystems/squashfs.txt | 8 +-
>>>> fs/squashfs/Kconfig | 15 +++
>>>> fs/squashfs/Makefile | 1 +
>>>> fs/squashfs/decompressor.c | 7 ++
>>>> fs/squashfs/decompressor.h | 4 +
>>>> fs/squashfs/lz4_wrapper.c | 163 ++++++++++++++++++++++++++++++++
>>>> fs/squashfs/squashfs_fs.h | 1 +
>>>> 7 files changed, 195 insertions(+), 4 deletions(-)
>>>> create mode 100644 fs/squashfs/lz4_wrapper.c
>>>>
>>>> These patches are also available in the git tree here:
>>>>
>>>> browse: https://git.kernel.org/cgit/linux/kernel/git/pkl/squashfs-lz4.git
>>>> git clone: git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-lz4.git
>>>>
>>>> LZ4 support has (obviously) also been added to the squashfs-tools
>>>> (Mksquashfs and Unsquashfs). This is available from the Squashfs-tools
>>>> git repository here:
>>>>
>>>> browse: https://git.kernel.org/cgit/fs/squashfs/squashfs-tools.git
>>>> git clone: git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
>>>>
>>>> When building the squashfs-tools edit the Makefile to enable LZ4
>>>> support (by default it is disabled).
>>>>
>>>> LZ4 compression can be specified by using the -comp option, e.g.
>>>> % mksquashfs xxx img.sqsh -comp lz4
>>>>
>>>> The use of LZ4 high compression can be specified using -Xhc, e.g.
>>>>
>>>> % mksquashfs xxx img.sqsh -comp lz4 -Xhc
>>>>
>>>> Phillip
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>>
>>>
>>>
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 0/2] Squashfs: add LZ4 compression
From: Gu Zheng @ 2013-07-22 6:04 UTC (permalink / raw)
To: Phillip Lougher
Cc: Phillip Lougher, linux-kernel, linux-fsdevel, linux-embedded
In-Reply-To: <CAB3wodewRSGwKt_mKP7e-HpA=b7hCUedBsAcasFxWC5ZPJ5btg@mail.gmail.com>
On 07/22/2013 01:07 PM, Phillip Lougher wrote:
> On 22 July 2013 04:05, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
>> Hi Phillip,
>> Have some tests been carried out to confirm that Squashfs really
>> can get benefit from LZ4 compression, comparing with lzo?
>
> This seems to be a loaded question, in that it seems to be trying to
> reopen the "why add lz4 when we already have lzo" debate all over
> again. As LZ4 has been merged to mainline, this appears to be a
> question that has already been answered.
No, they are different. LZ4 can be merged to mainline, because we can
see the benefit(faster compressing speed under the enabled unaligned
memory access) it brings to us comparing with lzo.
But it's hard to say that it also really can bring benefit to Squashfs.
>
> As far as Squashfs is concerned, I believe it is important to give
> people the choice of using LZ4 to compress Squashfs filesystems now
> its been mainlined. As far as expected benefits are concerned,
> Squashfs' use in embedded systems is very similar to compressing
> kernels and initramfs data, in that it tends to be used to compress
> root filesystems. As such the benefits of using LZ4 in Squashfs
> should be broadly similar to using LZ4 to compress kernels and
> initramfs data. Ultimately it is up to people to experiment and
> choose whatever compression is best for their systems.
Yes, but the premise is that using LZ4 in Squashfs is better than lzo
in at least one actual situation.
>
> People are welcome to try the patches out and report their findings.
Let's look and see other guys' feedbacks, they are more persuasive.:)
Regards,
Gu
>
> Phillip
>
>>
>> Thanks,
>> Gu
>>
>> On 07/22/2013 10:21 AM, Phillip Lougher wrote:
>>
>>> Hi
>>>
>>> Now that LZ4 compression support is in 3.11-rc1, I have written the
>>> following two patches for Squashfs to use it.
>>>
>>> Phillip Lougher (2):
>>> Squashfs: add LZ4 compression support
>>> Squashfs: Add LZ4 compression configuration option
>>>
>>> Documentation/filesystems/squashfs.txt | 8 +-
>>> fs/squashfs/Kconfig | 15 +++
>>> fs/squashfs/Makefile | 1 +
>>> fs/squashfs/decompressor.c | 7 ++
>>> fs/squashfs/decompressor.h | 4 +
>>> fs/squashfs/lz4_wrapper.c | 163 ++++++++++++++++++++++++++++++++
>>> fs/squashfs/squashfs_fs.h | 1 +
>>> 7 files changed, 195 insertions(+), 4 deletions(-)
>>> create mode 100644 fs/squashfs/lz4_wrapper.c
>>>
>>> These patches are also available in the git tree here:
>>>
>>> browse: https://git.kernel.org/cgit/linux/kernel/git/pkl/squashfs-lz4.git
>>> git clone: git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-lz4.git
>>>
>>> LZ4 support has (obviously) also been added to the squashfs-tools
>>> (Mksquashfs and Unsquashfs). This is available from the Squashfs-tools
>>> git repository here:
>>>
>>> browse: https://git.kernel.org/cgit/fs/squashfs/squashfs-tools.git
>>> git clone: git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
>>>
>>> When building the squashfs-tools edit the Makefile to enable LZ4
>>> support (by default it is disabled).
>>>
>>> LZ4 compression can be specified by using the -comp option, e.g.
>>> % mksquashfs xxx img.sqsh -comp lz4
>>>
>>> The use of LZ4 high compression can be specified using -Xhc, e.g.
>>>
>>> % mksquashfs xxx img.sqsh -comp lz4 -Xhc
>>>
>>> Phillip
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH 0/2] Squashfs: add LZ4 compression
From: Phillip Lougher @ 2013-07-22 5:07 UTC (permalink / raw)
To: Gu Zheng; +Cc: Phillip Lougher, linux-kernel, linux-fsdevel, linux-embedded
In-Reply-To: <51ECA17A.3060401@cn.fujitsu.com>
On 22 July 2013 04:05, Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
> Hi Phillip,
> Have some tests been carried out to confirm that Squashfs really
> can get benefit from LZ4 compression, comparing with lzo?
This seems to be a loaded question, in that it seems to be trying to
reopen the "why add lz4 when we already have lzo" debate all over
again. As LZ4 has been merged to mainline, this appears to be a
question that has already been answered.
As far as Squashfs is concerned, I believe it is important to give
people the choice of using LZ4 to compress Squashfs filesystems now
its been mainlined. As far as expected benefits are concerned,
Squashfs' use in embedded systems is very similar to compressing
kernels and initramfs data, in that it tends to be used to compress
root filesystems. As such the benefits of using LZ4 in Squashfs
should be broadly similar to using LZ4 to compress kernels and
initramfs data. Ultimately it is up to people to experiment and
choose whatever compression is best for their systems.
People are welcome to try the patches out and report their findings.
Phillip
>
> Thanks,
> Gu
>
> On 07/22/2013 10:21 AM, Phillip Lougher wrote:
>
>> Hi
>>
>> Now that LZ4 compression support is in 3.11-rc1, I have written the
>> following two patches for Squashfs to use it.
>>
>> Phillip Lougher (2):
>> Squashfs: add LZ4 compression support
>> Squashfs: Add LZ4 compression configuration option
>>
>> Documentation/filesystems/squashfs.txt | 8 +-
>> fs/squashfs/Kconfig | 15 +++
>> fs/squashfs/Makefile | 1 +
>> fs/squashfs/decompressor.c | 7 ++
>> fs/squashfs/decompressor.h | 4 +
>> fs/squashfs/lz4_wrapper.c | 163 ++++++++++++++++++++++++++++++++
>> fs/squashfs/squashfs_fs.h | 1 +
>> 7 files changed, 195 insertions(+), 4 deletions(-)
>> create mode 100644 fs/squashfs/lz4_wrapper.c
>>
>> These patches are also available in the git tree here:
>>
>> browse: https://git.kernel.org/cgit/linux/kernel/git/pkl/squashfs-lz4.git
>> git clone: git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-lz4.git
>>
>> LZ4 support has (obviously) also been added to the squashfs-tools
>> (Mksquashfs and Unsquashfs). This is available from the Squashfs-tools
>> git repository here:
>>
>> browse: https://git.kernel.org/cgit/fs/squashfs/squashfs-tools.git
>> git clone: git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
>>
>> When building the squashfs-tools edit the Makefile to enable LZ4
>> support (by default it is disabled).
>>
>> LZ4 compression can be specified by using the -comp option, e.g.
>> % mksquashfs xxx img.sqsh -comp lz4
>>
>> The use of LZ4 high compression can be specified using -Xhc, e.g.
>>
>> % mksquashfs xxx img.sqsh -comp lz4 -Xhc
>>
>> Phillip
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] Squashfs: add LZ4 compression support
From: Joe Perches @ 2013-07-22 4:35 UTC (permalink / raw)
To: Phillip Lougher; +Cc: linux-kernel, linux-fsdevel, linux-embedded
In-Reply-To: <1374459663-15363-2-git-send-email-phillip@squashfs.org.uk>
On Mon, 2013-07-22 at 03:21 +0100, Phillip Lougher wrote:
> Add support for reading file systems compressed with the
> LZ4 compression algorithm.
Some whitespace trivia and a naming comment.
> diff --git a/fs/squashfs/lz4_wrapper.c b/fs/squashfs/lz4_wrapper.c
[]
> +static void *lz4_init(struct squashfs_sb_info *msblk, void *buff, int len)
[]
> + /* LZ4 compressed filesystems always have compression options */
> + if(comp_opts == NULL || len < sizeof(*comp_opts)) {
space after ifs please.
> + if(le32_to_cpu(comp_opts->version) != LZ4_LEGACY) {
> +
> +
> +static void lz4_free(void *strm)
Single blank line between functions
> +static int lz4_uncompress(struct squashfs_sb_info *msblk, void **buffer,
> + struct buffer_head **bh, int b, int offset, int length, int srclength,
> + int pages)
> +{
> + struct squashfs_lz4 *stream = msblk->stream;
> + void *buff = stream->input;
It's not particularly nice to have both buffer and buff
in the same function.
Maybe void *input though char *input would be better.
> + int avail, i, bytes = length, res;
> + size_t dest_len = srclength;
> +
> + mutex_lock(&msblk->read_data_mutex);
> +
> + for (i = 0; i < b; i++) {
> + wait_on_buffer(bh[i]);
> + if (!buffer_uptodate(bh[i]))
> + goto block_release;
> +
> + avail = min(bytes, msblk->devblksize - offset);
> + memcpy(buff, bh[i]->b_data + offset, avail);
> + buff += avail;
> + bytes -= avail;
> + offset = 0;
> + put_bh(bh[i]);
> + }
^ permalink raw reply
* Re: [PATCH 0/2] Squashfs: add LZ4 compression
From: Gu Zheng @ 2013-07-22 3:05 UTC (permalink / raw)
To: Phillip Lougher; +Cc: linux-kernel, linux-fsdevel, linux-embedded
In-Reply-To: <1374459663-15363-1-git-send-email-phillip@squashfs.org.uk>
Hi Phillip,
Have some tests been carried out to confirm that Squashfs really
can get benefit from LZ4 compression, comparing with lzo?
Thanks,
Gu
On 07/22/2013 10:21 AM, Phillip Lougher wrote:
> Hi
>
> Now that LZ4 compression support is in 3.11-rc1, I have written the
> following two patches for Squashfs to use it.
>
> Phillip Lougher (2):
> Squashfs: add LZ4 compression support
> Squashfs: Add LZ4 compression configuration option
>
> Documentation/filesystems/squashfs.txt | 8 +-
> fs/squashfs/Kconfig | 15 +++
> fs/squashfs/Makefile | 1 +
> fs/squashfs/decompressor.c | 7 ++
> fs/squashfs/decompressor.h | 4 +
> fs/squashfs/lz4_wrapper.c | 163 ++++++++++++++++++++++++++++++++
> fs/squashfs/squashfs_fs.h | 1 +
> 7 files changed, 195 insertions(+), 4 deletions(-)
> create mode 100644 fs/squashfs/lz4_wrapper.c
>
> These patches are also available in the git tree here:
>
> browse: https://git.kernel.org/cgit/linux/kernel/git/pkl/squashfs-lz4.git
> git clone: git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-lz4.git
>
> LZ4 support has (obviously) also been added to the squashfs-tools
> (Mksquashfs and Unsquashfs). This is available from the Squashfs-tools
> git repository here:
>
> browse: https://git.kernel.org/cgit/fs/squashfs/squashfs-tools.git
> git clone: git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
>
> When building the squashfs-tools edit the Makefile to enable LZ4
> support (by default it is disabled).
>
> LZ4 compression can be specified by using the -comp option, e.g.
> % mksquashfs xxx img.sqsh -comp lz4
>
> The use of LZ4 high compression can be specified using -Xhc, e.g.
>
> % mksquashfs xxx img.sqsh -comp lz4 -Xhc
>
> Phillip
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH 2/2] Squashfs: Add LZ4 compression configuration option
From: Phillip Lougher @ 2013-07-22 2:21 UTC (permalink / raw)
To: linux-kernel, linux-fsdevel, linux-embedded; +Cc: Phillip Lougher
In-Reply-To: <1374459663-15363-1-git-send-email-phillip@squashfs.org.uk>
Add the glue code, and also update the documentation.
Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
---
Documentation/filesystems/squashfs.txt | 8 ++++----
fs/squashfs/Kconfig | 15 +++++++++++++++
fs/squashfs/Makefile | 1 +
fs/squashfs/decompressor.c | 7 +++++++
fs/squashfs/decompressor.h | 4 ++++
5 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt
index 403c090..e5274f8 100644
--- a/Documentation/filesystems/squashfs.txt
+++ b/Documentation/filesystems/squashfs.txt
@@ -2,10 +2,10 @@ SQUASHFS 4.0 FILESYSTEM
=======================
Squashfs is a compressed read-only filesystem for Linux.
-It uses zlib/lzo/xz compression to compress files, inodes and directories.
-Inodes in the system are very small and all blocks are packed to minimise
-data overhead. Block sizes greater than 4K are supported up to a maximum
-of 1Mbytes (default block size 128K).
+It uses zlib, lz4, lzo, or xz compression to compress files, inodes and
+directories. Inodes in the system are very small and all blocks are packed to
+minimise data overhead. Block sizes greater than 4K are supported up to a
+maximum of 1Mbytes (default block size 128K).
Squashfs is intended for general read-only filesystem use, for archival
use (i.e. in cases where a .tar.gz file may be used), and in constrained
diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
index c70111e..257f934 100644
--- a/fs/squashfs/Kconfig
+++ b/fs/squashfs/Kconfig
@@ -48,6 +48,21 @@ config SQUASHFS_ZLIB
If unsure, say Y.
+config SQUASHFS_LZ4
+ bool "Include support for LZ4 compressed file systems"
+ depends on SQUASHFS
+ select LZ4_DECOMPRESS
+ help
+ Saying Y here includes support for reading Squashfs file systems
+ compressed with LZ4 compression. LZ4 compression is mainly
+ aimed at embedded systems with slower CPUs where the overheads
+ of zlib are too high.
+
+ LZ4 is not the standard compression used in Squashfs and so most
+ file systems will be readable without selecting this option.
+
+ If unsure, say N.
+
config SQUASHFS_LZO
bool "Include support for LZO compressed file systems"
depends on SQUASHFS
diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
index 110b047..4a80ca7 100644
--- a/fs/squashfs/Makefile
+++ b/fs/squashfs/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SQUASHFS) += squashfs.o
squashfs-y += block.o cache.o dir.o export.o file.o fragment.o id.o inode.o
squashfs-y += namei.o super.o symlink.o decompressor.o
squashfs-$(CONFIG_SQUASHFS_XATTR) += xattr.o xattr_id.o
+squashfs-$(CONFIG_SQUASHFS_LZ4) += lz4_wrapper.o
squashfs-$(CONFIG_SQUASHFS_LZO) += lzo_wrapper.o
squashfs-$(CONFIG_SQUASHFS_XZ) += xz_wrapper.o
squashfs-$(CONFIG_SQUASHFS_ZLIB) += zlib_wrapper.o
diff --git a/fs/squashfs/decompressor.c b/fs/squashfs/decompressor.c
index 3f6271d..ae60211 100644
--- a/fs/squashfs/decompressor.c
+++ b/fs/squashfs/decompressor.c
@@ -40,6 +40,12 @@ static const struct squashfs_decompressor squashfs_lzma_unsupported_comp_ops = {
NULL, NULL, NULL, LZMA_COMPRESSION, "lzma", 0
};
+#ifndef CONFIG_SQUASHFS_LZ4
+static const struct squashfs_decompressor squashfs_lz4_comp_ops = {
+ NULL, NULL, NULL, LZ4_COMPRESSION, "lz4", 0
+};
+#endif
+
#ifndef CONFIG_SQUASHFS_LZO
static const struct squashfs_decompressor squashfs_lzo_comp_ops = {
NULL, NULL, NULL, LZO_COMPRESSION, "lzo", 0
@@ -64,6 +70,7 @@ static const struct squashfs_decompressor squashfs_unknown_comp_ops = {
static const struct squashfs_decompressor *decompressor[] = {
&squashfs_zlib_comp_ops,
+ &squashfs_lz4_comp_ops,
&squashfs_lzo_comp_ops,
&squashfs_xz_comp_ops,
&squashfs_lzma_unsupported_comp_ops,
diff --git a/fs/squashfs/decompressor.h b/fs/squashfs/decompressor.h
index 330073e..a9fbdd2 100644
--- a/fs/squashfs/decompressor.h
+++ b/fs/squashfs/decompressor.h
@@ -52,6 +52,10 @@ static inline int squashfs_decompress(struct squashfs_sb_info *msblk,
extern const struct squashfs_decompressor squashfs_xz_comp_ops;
#endif
+#ifdef CONFIG_SQUASHFS_LZ4
+extern const struct squashfs_decompressor squashfs_lz4_comp_ops;
+#endif
+
#ifdef CONFIG_SQUASHFS_LZO
extern const struct squashfs_decompressor squashfs_lzo_comp_ops;
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] Squashfs: add LZ4 compression support
From: Phillip Lougher @ 2013-07-22 2:21 UTC (permalink / raw)
To: linux-kernel, linux-fsdevel, linux-embedded; +Cc: Phillip Lougher
In-Reply-To: <1374459663-15363-1-git-send-email-phillip@squashfs.org.uk>
Add support for reading file systems compressed with the
LZ4 compression algorithm.
This patch adds the LZ4 decompressor wrapper code.
Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
---
fs/squashfs/lz4_wrapper.c | 163 +++++++++++++++++++++++++++++++++++++++++++++
fs/squashfs/squashfs_fs.h | 1 +
2 files changed, 164 insertions(+)
create mode 100644 fs/squashfs/lz4_wrapper.c
diff --git a/fs/squashfs/lz4_wrapper.c b/fs/squashfs/lz4_wrapper.c
new file mode 100644
index 0000000..681ed94
--- /dev/null
+++ b/fs/squashfs/lz4_wrapper.c
@@ -0,0 +1,163 @@
+/*
+ * Squashfs - a compressed read only filesystem for Linux
+ *
+ * Copyright (c) 2013
+ * Phillip Lougher <phillip@squashfs.org.uk>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2,
+ * or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * lz4_wrapper.c
+ */
+
+#include <linux/buffer_head.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/lz4.h>
+
+#include "squashfs_fs.h"
+#include "squashfs_fs_sb.h"
+#include "squashfs.h"
+#include "decompressor.h"
+
+#define LZ4_LEGACY 1
+
+struct lz4_comp_opts {
+ __le32 version;
+ __le32 flags;
+};
+
+struct squashfs_lz4 {
+ void *input;
+ void *output;
+};
+
+
+
+static void *lz4_init(struct squashfs_sb_info *msblk, void *buff, int len)
+{
+ struct lz4_comp_opts *comp_opts = buff;
+ int block_size = max_t(int, msblk->block_size, SQUASHFS_METADATA_SIZE);
+ struct squashfs_lz4 *stream;
+ int err = -ENOMEM;
+
+ /* LZ4 compressed filesystems always have compression options */
+ if(comp_opts == NULL || len < sizeof(*comp_opts)) {
+ err = -EIO;
+ goto failed;
+ }
+ if(le32_to_cpu(comp_opts->version) != LZ4_LEGACY) {
+ /* LZ4 format currently used by the kernel is the 'legacy'
+ * format */
+ ERROR("Unknown LZ4 version\n");
+ err = -EINVAL;
+ goto failed;
+ }
+
+ stream = kzalloc(sizeof(*stream), GFP_KERNEL);
+ if (stream == NULL)
+ goto failed;
+ stream->input = vmalloc(block_size);
+ if (stream->input == NULL)
+ goto failed2;
+ stream->output = vmalloc(block_size);
+ if (stream->output == NULL)
+ goto failed3;
+
+ return stream;
+
+failed3:
+ vfree(stream->input);
+failed2:
+ kfree(stream);
+failed:
+ ERROR("Failed to initialise LZ4 decompressor\n");
+ return ERR_PTR(err);
+}
+
+
+static void lz4_free(void *strm)
+{
+ struct squashfs_lz4 *stream = strm;
+
+ if (stream) {
+ vfree(stream->input);
+ vfree(stream->output);
+ }
+ kfree(stream);
+}
+
+
+static int lz4_uncompress(struct squashfs_sb_info *msblk, void **buffer,
+ struct buffer_head **bh, int b, int offset, int length, int srclength,
+ int pages)
+{
+ struct squashfs_lz4 *stream = msblk->stream;
+ void *buff = stream->input;
+ int avail, i, bytes = length, res;
+ size_t dest_len = srclength;
+
+ mutex_lock(&msblk->read_data_mutex);
+
+ for (i = 0; i < b; i++) {
+ wait_on_buffer(bh[i]);
+ if (!buffer_uptodate(bh[i]))
+ goto block_release;
+
+ avail = min(bytes, msblk->devblksize - offset);
+ memcpy(buff, bh[i]->b_data + offset, avail);
+ buff += avail;
+ bytes -= avail;
+ offset = 0;
+ put_bh(bh[i]);
+ }
+
+ res = lz4_decompress_unknownoutputsize(stream->input, length,
+ stream->output, &dest_len);
+ if (res)
+ goto failed;
+
+ bytes = dest_len;
+ for (i = 0, buff = stream->output; bytes && i < pages; i++) {
+ avail = min_t(int, bytes, PAGE_CACHE_SIZE);
+ memcpy(buffer[i], buff, avail);
+ buff += avail;
+ bytes -= avail;
+ }
+ if (bytes)
+ goto failed;
+
+ mutex_unlock(&msblk->read_data_mutex);
+ return dest_len;
+
+block_release:
+ for (; i < b; i++)
+ put_bh(bh[i]);
+
+failed:
+ mutex_unlock(&msblk->read_data_mutex);
+
+ ERROR("lz4 decompression failed, data probably corrupt\n");
+ return -EIO;
+}
+
+const struct squashfs_decompressor squashfs_lz4_comp_ops = {
+ .init = lz4_init,
+ .free = lz4_free,
+ .decompress = lz4_uncompress,
+ .id = LZ4_COMPRESSION,
+ .name = "lz4",
+ .supported = 1
+};
diff --git a/fs/squashfs/squashfs_fs.h b/fs/squashfs/squashfs_fs.h
index 9e2349d..ee0be5c 100644
--- a/fs/squashfs/squashfs_fs.h
+++ b/fs/squashfs/squashfs_fs.h
@@ -237,6 +237,7 @@ struct meta_index {
#define LZMA_COMPRESSION 2
#define LZO_COMPRESSION 3
#define XZ_COMPRESSION 4
+#define LZ4_COMPRESSION 5
struct squashfs_super_block {
__le32 s_magic;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] Squashfs: add LZ4 compression
From: Phillip Lougher @ 2013-07-22 2:21 UTC (permalink / raw)
To: linux-kernel, linux-fsdevel, linux-embedded; +Cc: Phillip Lougher
Hi
Now that LZ4 compression support is in 3.11-rc1, I have written the
following two patches for Squashfs to use it.
Phillip Lougher (2):
Squashfs: add LZ4 compression support
Squashfs: Add LZ4 compression configuration option
Documentation/filesystems/squashfs.txt | 8 +-
fs/squashfs/Kconfig | 15 +++
fs/squashfs/Makefile | 1 +
fs/squashfs/decompressor.c | 7 ++
fs/squashfs/decompressor.h | 4 +
fs/squashfs/lz4_wrapper.c | 163 ++++++++++++++++++++++++++++++++
fs/squashfs/squashfs_fs.h | 1 +
7 files changed, 195 insertions(+), 4 deletions(-)
create mode 100644 fs/squashfs/lz4_wrapper.c
These patches are also available in the git tree here:
browse: https://git.kernel.org/cgit/linux/kernel/git/pkl/squashfs-lz4.git
git clone: git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-lz4.git
LZ4 support has (obviously) also been added to the squashfs-tools
(Mksquashfs and Unsquashfs). This is available from the Squashfs-tools
git repository here:
browse: https://git.kernel.org/cgit/fs/squashfs/squashfs-tools.git
git clone: git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
When building the squashfs-tools edit the Makefile to enable LZ4
support (by default it is disabled).
LZ4 compression can be specified by using the -comp option, e.g.
% mksquashfs xxx img.sqsh -comp lz4
The use of LZ4 high compression can be specified using -Xhc, e.g.
% mksquashfs xxx img.sqsh -comp lz4 -Xhc
Phillip
^ permalink raw reply
* ELCE CFP ends July 21st
From: Bill Traynor @ 2013-07-16 3:01 UTC (permalink / raw)
To: linux-embedded
Note the the CFP for ELCE ends July 21st.
http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/cfp
^ permalink raw reply
* Re: Boot time: Optimize CPU bring up?
From: Abbas Raza @ 2013-06-29 22:34 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <51B0770E.3070601@de.bosch.com>
Dirk Behme <dirk.behme <at> de.bosch.com> writes:
>
> Hi,
>
> on a ARMv7 Freescale i.MX6 based system we are looking at optimizing the
> kernel boot time. Booting a 3.5.7 kernel with SMP=y and the kernel
> option 'nosmp' (the i.MX6 has single, dual and quad CPU versions) we get
>
> [ 0.255927] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7
> counters available
> [ 0.256033] Setting up static identity map for 0x10426a28 - 0x10426a80
> [ 0.260204] initcall spawn_ksoftirqd+0x0/0x58 returned 0 after 9765 usecs
> [ 0.270363] initcall init_workqueues+0x0/0x39c returned 0 after 9765
> usecs
> [ 0.290265] initcall cpu_stop_init+0x0/0xd0 returned 0 after 19531 usecs
> [ 0.310449] initcall rcu_spawn_kthreads+0x0/0xc0 returned 0 after
> 19531 usecs
> [ 0.310699] Brought up 1 CPUs
> [ 0.310712] SMP: Total of 1 processors activated (1581.05 BogoMIPS).
>
> I.e. ~55ms just for bringing up the 1 CPU.
>
> Looking into some details, e.g. cpu_stop_init(), the ~19531 usecs are
> there because the system 'hangs' 2 jiffies (CONFIG_HZ=100) in
> cpu_v7_do_idle().
>
> For testing purposes switching to CONFIG_HZ=1000 reduces above 54ms to
> just ~4ms. But we are unsure to switch the whole system to
> CONFIG_HZ=1000 just to optimize this part of the boot process.
>
> Does anybody know why all the above parts are idling for some jiffies?
> Is there any other optimization than CONFIG_HZ=1000 possible?
>
> In case there are any patches floating around or this was already
> discussed, any link would be nice.
>
> Many thanks and best regards
>
> Dirk
>
Hi Dirk,
I have done some analysis to find out where it is idling for some jiffies
during kernel boot. I have compiled my findings below and also suggested
some solutions. Please take a look
starting from start_kernel
==========================
0) scheduler init routine creates idle thread
1) rest_init() is called from start_kernel()
2 2 threads are created kernel_init and kthreadd
3) schedule() called for first time
4) kthreadd scheduled first by cfs scheduler
5) kthreadd looks if there is any new thread to be created
6) since there is no new thread to be created so it set state
TASK_INTERRUPTIBLE and calls schedule()
7) now kernel_init is picked by scheduler
8) kernel_init calls do_pre_smp_initcalls
9) when spawn_ksoftirqd initcall is run by kernel init thread, it goes to
create a kthread(ksoftirqd)
10) for this it wakes up kthreadd
11) a new kthread is created by kthreadd
12) kthreadd looks if any other kthread to be created in create list
13) since there is no kthread to be created so it calls scheduler with state
TASK_INTERRUPTIBLE
14) now scheduler picks kernel init thread to br executed next
15) kernel init thread calls wait_for_completion(&create.done) which is
supposed to be set by newly created kthread.
16) schedule timeout occurs and scheduler next picks newly created kthread.
17) newly created kthread sets state TASK_UNINTERRUPTIBLE and sends complete
signal create.done
18) scheduler then schedules kernel init thread which goes to bind this
newly created kthread to cpu0 using kbind().
19) kernel init thread checks if newly created kthread has been dequeued.
20) if not dequeued yet, it means its still in run queue.
21) if 20 is yes then kernel init goes to sleep
for HZ=100, it sleeps for 10ms while for HZ=1000, it sleeps for 1ms
if (unlikely(on_rq)) {
ktime_t to = ktime_set(0, NSEC_PER_SEC/HZ);
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_hrtimeout(&to, HRTIMER_MODE_REL);
continue;
}
22) Now scheduler picks newly created kthread from run queue.
23) this kthread is dequeues by calling schedule with TASK_UNINTERRUPTIBLE
state set
24) Now at this time all the kthreads are in dequeued state except idle i.e
kthreadd --> dequeued
kernel init --> dequeued
kthread (ksoftirqd) --> dequeued
25) Nothing left on run queue so scheduler calls idle thread.
26) Now system runs in idle thread until 1 timer tick is received i.e for
10ms (HZ=100)
27) when 1 timer tick is received, system get out from idle thread
28) scheduler wakes up kernel init thread
29) kernel init thread again checks if kthread (ksoftirqd) has been dequeued
30) if it founds it dequeued, it finally binds it with cpu0
31) kernel init continues execution and kthread (ksoftirqd) is woken up and
put on run queue again for cpu0.
32) kthread gets scheduled later and run_ksoftirqd() is called then.
So 1 timer tick is always consumed in idle loop in step 21 while booting
whenever there is a need to bind a kthread to cpu. The same thing happens with
early initcalls init_workqueues and cpu_stop_init causing the boot time to
increase.
Possible solutions to decrease the boot time:
==============================================
--------------------------------------------------------
1) Increasing CONFIG_HZ=100 (default) to CONFIG)_HZ=1000
--------------------------------------------------------
Increasing the timer ticks i.e HZ=1000 which will cause step 21 to sleep for
only 1ms.
draw backs: increasing the timer ticks decreases throughput.
OR
--------------------------------
2) use CONFIG_PREEMPT_VOLUNTARY:
--------------------------------
draw backs: Reduces the maximum latency of rescheduling at the cost of
slightly lower throughput.
OR
-------------------------------------------------------------------
3) Don't wait before binding a kthread to cpu0 in presmp initcalls:
-------------------------------------------------------------------
Since we are running presmp initcalls(only cpu0 is up), why do we need to
wait before binding a kthread to cpu0?
Souldn't we skip this wait like it is done in !SMP case (assuming that
presmp just equals !SMP)
#ifdef CONFIG_SMP
void scheduler_ipi(void);
extern unsigned long wait_task_inactive(struct task_struct *, long match_state);
#else
static inline void scheduler_ipi(void) { }
static inline unsigned long wait_task_inactive(struct task_struct *p,
long match_state)
{
return 1;
}
#endif
Above piece of code does not wait in case of !SMP. I beleive that same
should be done for presmp initcalls. But i haven't found any such
implementations
in code.
draw backs: in my opinion there shouldn't be any. Comments needed.
OR
-----------------------------------------------------------
4) Don't sleep for 1 tick before binding a kthread to cpu0:
-----------------------------------------------------------
1 timer tick is always consumed in idle loop in step 21 while booting
whenever there is a need to bind a kthread to cpu. Why do we need to sleep
kernel init thread for 1 tick ? why don't we just call the schedule() in
wait_task_inactive(), yeild the cpu so that kthread can get scheduled ASAP
and gets dequeued. kernel init thread will be scheduled next ASAP and it
will get out of wait_task_inactive (Does'nt it seem quicker as compared to
sleeping for 1 tick?)
if (unlikely(on_rq)) {
//ktime_t to = ktime_set(0, NSEC_PER_SEC/HZ);
//set_current_state(TASK_UNINTERRUPTIBLE);
//schedule_hrtimeout(&to, HRTIMER_MODE_REL);
schedule();
continue;
}
Above changes will cause step 21 to never sleep.
or (if sleeping is necessary)
Modifying the above code to sleep for smaller time (1ms in case of HZ=100)
but for this i guess we will need hrtimer to work at that time. But it was
found that hrtimer does not work at that time for any resolution higher that
10ms(in case of HZ=100).
draw backs: not known yet. Comments needed.
It would be very nice if we can get some comments on above analysis from
community.
Thanks .
Abbas Raza
^ permalink raw reply
* Re: [PATCH 01/32] init.h: remove __cpuinit sections from the kernel
From: Joe Perches @ 2013-06-24 22:10 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-kernel, linux-embedded
In-Reply-To: <1372103478.1245.23.camel@joe-AO722>
On Mon, 2013-06-24 at 12:51 -0700, Joe Perches wrote:
> On Mon, 2013-06-24 at 15:30 -0400, Paul Gortmaker wrote:
> > The __cpuinit type of throwaway sections might have made sense
> > some time ago when RAM was more constrained, but now the savings
> > do not offset the cost and complications. For example, the fix in
> > commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
> > is a good example of the nasty type of bugs that can be created
> > with improper use of the various __init prefixes.
>
> Hi Paul.
>
> Could you please post the sizes of a generic kernel build
> with and without this?
Nevermind...
I just checked using readelf -S.
Seems sensible to me.
^ permalink raw reply
* Re: [PATCH 01/32] init.h: remove __cpuinit sections from the kernel
From: Joe Perches @ 2013-06-24 19:51 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-kernel, linux-embedded
In-Reply-To: <1372102237-8757-2-git-send-email-paul.gortmaker@windriver.com>
On Mon, 2013-06-24 at 15:30 -0400, Paul Gortmaker wrote:
> The __cpuinit type of throwaway sections might have made sense
> some time ago when RAM was more constrained, but now the savings
> do not offset the cost and complications. For example, the fix in
> commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
> is a good example of the nasty type of bugs that can be created
> with improper use of the various __init prefixes.
Hi Paul.
Could you please post the sizes of a generic kernel build
with and without this?
^ permalink raw reply
* Re: [PATCH 1/2] ext2: Reduce object size when !CONFIG_PRINTK
From: Joe Perches @ 2013-06-21 17:06 UTC (permalink / raw)
To: Jan Kara
Cc: linux-ext4, Theodore Ts'o, linux-kernel, linux-embedded,
openwrt-hackers
In-Reply-To: <20130621165049.GP13932@quack.suse.cz>
On Fri, 2013-06-21 at 18:50 +0200, Jan Kara wrote:
> On Tue 18-06-13 10:14:39, Joe Perches wrote:
> > Reducing the object size ~5kb/15% could be useful for embedded
> > systems.
> >
> > Add #ifdef CONFIG_PRINTK #else #endif blocks
> > to hold formats and arguments, passing " " to
> > functions when !CONFIG_PRINTK and still verifying
> > format and arguments with no_printk.
> >
> > $ size fs/ext2/built-in.o*
> > text data bss dec hex filename
> > 31297 44 4 31345 7a71 fs/ext2/built-in.o.ext2.new
> > 36288 44 4 36336 8df0 fs/ext2/built-in.o.ext2.old
> >
> > $ grep -E "CONFIG_EXT2|CONFIG_PRINTK" .config
> > # CONFIG_PRINTK is not set
> > CONFIG_EXT2_FS=y
> > # CONFIG_EXT2_FS_XATTR is not set
> > # CONFIG_EXT2_FS_XIP is not set
> I'm somewhat reluctant to merge this unless I know someone really
> cares. It looks a bit ugly to ifdef every function doing some printing just
> to reduce object size when CONFIG_PRINTK is disabled... And in future LTO
> might help us ;)
(adding cc's to linux-embedded and openwrt
maybe someone there cares)
Link time optimization might help some, but these calls
are still made and the strings could not be eliminated
without this.
Original patch: http://patchwork.kernel.org/patch/2744401/
^ permalink raw reply
* Re: [PATCH] ext4: Reduce object size when !CONFIG_PRINTK
From: Theodore Ts'o @ 2013-06-18 15:14 UTC (permalink / raw)
To: Joe Perches
Cc: linux-kernel, Dave Kleikamp, linux-fsdevel, linux-embedded,
Andreas Dilger, linux-ext4
In-Reply-To: <a629c1c6359886419e24179dbb04484a88e6b0f2.1370400427.git.joe@perches.com>
On Tue, Jun 04, 2013 at 07:55:05PM -0700, Joe Perches wrote:
> Reduce the object size ~10% could be useful for embedded
> systems.
>
> Add #ifdef CONFIG_PRINTK #else #endif blocks
> to hold formats and arguments, passing " " to
> functions when !CONFIG_PRINTK and still verifying
> format and arguments with no_printk.
>
> $ size fs/ext4/built-in.o*
> text data bss dec hex filename
> 239375 610 888 240873 3ace9 fs/ext4/built-in.o.new
> 264167 738 888 265793 40e41 fs/ext4/built-in.o.old
>
> $ grep -E "CONFIG_EXT4|CONFIG_PRINTK" .config
> # CONFIG_PRINTK is not set
> CONFIG_EXT4_FS=y
> CONFIG_EXT4_USE_FOR_EXT23=y
> CONFIG_EXT4_FS_POSIX_ACL=y
> # CONFIG_EXT4_FS_SECURITY is not set
> # CONFIG_EXT4_DEBUG is not set
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks.
- Ted
^ permalink raw reply
* Boot time: Optimize CPU bring up?
From: Dirk Behme @ 2013-06-06 11:48 UTC (permalink / raw)
To: linux-embedded; +Cc: dirk.behme
Hi,
on a ARMv7 Freescale i.MX6 based system we are looking at optimizing the
kernel boot time. Booting a 3.5.7 kernel with SMP=y and the kernel
option 'nosmp' (the i.MX6 has single, dual and quad CPU versions) we get
[ 0.255927] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7
counters available
[ 0.256033] Setting up static identity map for 0x10426a28 - 0x10426a80
[ 0.260204] initcall spawn_ksoftirqd+0x0/0x58 returned 0 after 9765 usecs
[ 0.270363] initcall init_workqueues+0x0/0x39c returned 0 after 9765
usecs
[ 0.290265] initcall cpu_stop_init+0x0/0xd0 returned 0 after 19531 usecs
[ 0.310449] initcall rcu_spawn_kthreads+0x0/0xc0 returned 0 after
19531 usecs
[ 0.310699] Brought up 1 CPUs
[ 0.310712] SMP: Total of 1 processors activated (1581.05 BogoMIPS).
I.e. ~55ms just for bringing up the 1 CPU.
Looking into some details, e.g. cpu_stop_init(), the ~19531 usecs are
there because the system 'hangs' 2 jiffies (CONFIG_HZ=100) in
cpu_v7_do_idle().
For testing purposes switching to CONFIG_HZ=1000 reduces above 54ms to
just ~4ms. But we are unsure to switch the whole system to
CONFIG_HZ=1000 just to optimize this part of the boot process.
Does anybody know why all the above parts are idling for some jiffies?
Is there any other optimization than CONFIG_HZ=1000 possible?
In case there are any patches floating around or this was already
discussed, any link would be nice.
Many thanks and best regards
Dirk
^ permalink raw reply
* [PATCH] ext4: Reduce object size when !CONFIG_PRINTK
From: Joe Perches @ 2013-06-05 2:55 UTC (permalink / raw)
To: linux-kernel
Cc: Dave Kleikamp, linux-fsdevel, linux-embedded, Theodore Ts'o,
Andreas Dilger, linux-ext4
Reduce the object size ~10% could be useful for embedded
systems.
Add #ifdef CONFIG_PRINTK #else #endif blocks
to hold formats and arguments, passing " " to
functions when !CONFIG_PRINTK and still verifying
format and arguments with no_printk.
$ size fs/ext4/built-in.o*
text data bss dec hex filename
239375 610 888 240873 3ace9 fs/ext4/built-in.o.new
264167 738 888 265793 40e41 fs/ext4/built-in.o.old
$ grep -E "CONFIG_EXT4|CONFIG_PRINTK" .config
# CONFIG_PRINTK is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_POSIX_ACL=y
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
Signed-off-by: Joe Perches <joe@perches.com>
---
fs/ext4/ext4.h | 80 +++++++++++++++++++++++++++++++++++++++++++++++----------
fs/ext4/super.c | 15 ++++++-----
2 files changed, 75 insertions(+), 20 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 019db3c..f4baeb06 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2164,42 +2164,96 @@ extern int ext4_alloc_flex_bg_array(struct super_block *sb,
ext4_group_t ngroup);
extern const char *ext4_decode_error(struct super_block *sb, int errno,
char nbuf[16]);
+
extern __printf(4, 5)
void __ext4_error(struct super_block *, const char *, unsigned int,
const char *, ...);
-#define ext4_error(sb, message...) __ext4_error(sb, __func__, \
- __LINE__, ## message)
extern __printf(5, 6)
-void ext4_error_inode(struct inode *, const char *, unsigned int, ext4_fsblk_t,
+void __ext4_error_inode(struct inode *, const char *, unsigned int, ext4_fsblk_t,
const char *, ...);
extern __printf(5, 6)
-void ext4_error_file(struct file *, const char *, unsigned int, ext4_fsblk_t,
+void __ext4_error_file(struct file *, const char *, unsigned int, ext4_fsblk_t,
const char *, ...);
extern void __ext4_std_error(struct super_block *, const char *,
unsigned int, int);
extern __printf(4, 5)
void __ext4_abort(struct super_block *, const char *, unsigned int,
const char *, ...);
-#define ext4_abort(sb, message...) __ext4_abort(sb, __func__, \
- __LINE__, ## message)
extern __printf(4, 5)
void __ext4_warning(struct super_block *, const char *, unsigned int,
const char *, ...);
-#define ext4_warning(sb, message...) __ext4_warning(sb, __func__, \
- __LINE__, ## message)
extern __printf(3, 4)
-void ext4_msg(struct super_block *, const char *, const char *, ...);
+void __ext4_msg(struct super_block *, const char *, const char *, ...);
extern void __dump_mmp_msg(struct super_block *, struct mmp_struct *mmp,
const char *, unsigned int, const char *);
-#define dump_mmp_msg(sb, mmp, msg) __dump_mmp_msg(sb, mmp, __func__, \
- __LINE__, msg)
extern __printf(7, 8)
void __ext4_grp_locked_error(const char *, unsigned int,
struct super_block *, ext4_group_t,
unsigned long, ext4_fsblk_t,
const char *, ...);
-#define ext4_grp_locked_error(sb, grp, message...) \
- __ext4_grp_locked_error(__func__, __LINE__, (sb), (grp), ## message)
+
+#ifdef CONFIG_PRINTK
+
+#define ext4_error_inode(inode, func, line, block, fmt, ...) \
+ __ext4_error_inode(inode, func, line, block, fmt, ##__VA_ARGS__)
+#define ext4_error_file(file, func, line, block, fmt, ...) \
+ __ext4_error_file(file, func, line, block, fmt, ##__VA_ARGS__)
+#define ext4_error(sb, fmt, ...) \
+ __ext4_error(sb, __func__, __LINE__, fmt, ##__VA_ARGS__)
+#define ext4_abort(sb, fmt, ...) \
+ __ext4_abort(sb, __func__, __LINE__, fmt, ##__VA_ARGS__)
+#define ext4_warning(sb, fmt, ...) \
+ __ext4_warning(sb, __func__, __LINE__, fmt, ##__VA_ARGS__)
+#define ext4_msg(sb, level, fmt, ...) \
+ __ext4_msg(sb, level, fmt, ##__VA_ARGS__)
+#define dump_mmp_msg(sb, mmp, msg) \
+ __dump_mmp_msg(sb, mmp, __func__, __LINE__, msg)
+#define ext4_grp_locked_error(sb, grp, ino, block, fmt, ...) \
+ __ext4_grp_locked_error(__func__, __LINE__, sb, grp, ino, block, \
+ fmt, ##__VA_ARGS__)
+
+#else
+
+#define ext4_error_inode(inode, func, line, block, fmt, ...) \
+do { \
+ no_printk(fmt, ##__VA_ARGS__); \
+ __ext4_error_inode(inode, "", 0, block, " "); \
+} while (0)
+#define ext4_error_file(file, func, line, block, fmt, ...) \
+do { \
+ no_printk(fmt, ##__VA_ARGS__); \
+ __ext4_error_file(file, "", 0, block, " "); \
+} while (0)
+#define ext4_error(sb, fmt, ...) \
+do { \
+ no_printk(fmt, ##__VA_ARGS__); \
+ __ext4_error(sb, "", 0, " "); \
+} while (0)
+#define ext4_abort(sb, fmt, ...) \
+do { \
+ no_printk(fmt, ##__VA_ARGS__); \
+ __ext4_abort(sb, "", 0, " "); \
+} while (0)
+#define ext4_warning(sb, fmt, ...) \
+do { \
+ no_printk(fmt, ##__VA_ARGS__); \
+ __ext4_warning(sb, "", 0, " "); \
+} while (0)
+#define ext4_msg(sb, level, fmt, ...) \
+do { \
+ no_printk(fmt, ##__VA_ARGS__); \
+ __ext4_msg(sb, "", " "); \
+} while (0)
+#define dump_mmp_msg(sb, mmp, msg) \
+ __dump_mmp_msg(sb, mmp, "", 0, "")
+#define ext4_grp_locked_error(sb, grp, ino, block, fmt, ...) \
+do { \
+ no_printk(fmt, ##__VA_ARGS__); \
+ __ext4_grp_locked_error("", 0, sb, grp, ino, block, " "); \
+} while (0)
+
+#endif
+
extern void ext4_update_dynamic_rev(struct super_block *sb);
extern int ext4_update_compat_feature(handle_t *handle, struct super_block *sb,
__u32 compat);
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index a9c1438..2e2825b 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -422,9 +422,9 @@ void __ext4_error(struct super_block *sb, const char *function,
ext4_handle_error(sb);
}
-void ext4_error_inode(struct inode *inode, const char *function,
- unsigned int line, ext4_fsblk_t block,
- const char *fmt, ...)
+void __ext4_error_inode(struct inode *inode, const char *function,
+ unsigned int line, ext4_fsblk_t block,
+ const char *fmt, ...)
{
va_list args;
struct va_format vaf;
@@ -451,9 +451,9 @@ void ext4_error_inode(struct inode *inode, const char *function,
ext4_handle_error(inode->i_sb);
}
-void ext4_error_file(struct file *file, const char *function,
- unsigned int line, ext4_fsblk_t block,
- const char *fmt, ...)
+void __ext4_error_file(struct file *file, const char *function,
+ unsigned int line, ext4_fsblk_t block,
+ const char *fmt, ...)
{
va_list args;
struct va_format vaf;
@@ -580,7 +580,8 @@ void __ext4_abort(struct super_block *sb, const char *function,
panic("EXT4-fs panic from previous error\n");
}
-void ext4_msg(struct super_block *sb, const char *prefix, const char *fmt, ...)
+void __ext4_msg(struct super_block *sb,
+ const char *prefix, const char *fmt, ...)
{
struct va_format vaf;
va_list args;
--
1.8.1.2.459.gbcd45b4.dirty
^ permalink raw reply related
* Re: Need help to measure and tune the latency in Linux RT
From: Ashoka K @ 2013-05-29 6:02 UTC (permalink / raw)
To: Android Techies; +Cc: linux-embedded, linux-newbie
In-Reply-To: <CAPo1LyXaqrGW0rqgvtaEJMoR1Y6NrTdVhV4Jb_gAp_N1ggwu0Q@mail.gmail.com>
Hello Android Techies and others,
I am still debugging this issue to understand the traces generated. I
am debugging at this level for first time, and now i am bit familiar
with traces.
To summarize again:
I have ARM OMAP embedded system, running vanilla Linux 2.6.33-29 cross
compiled with PREEMPT patch. There is a application, say Thread_1 (RR,
with highest priority) which need to send and receive data every 2ms,
or 4ms or 8 ms etc. (configurable). This data is small and atmost it
will be 1 ethernet frame (1500 bytes). So i expect this application to
execute for very short time but regularly without missing deadlines
(There is deviation allowed with watchdog timeout but in worst cases).
There is another process running (RR, lower pri than Thread_1) on same
system which transfers images on request from outside users/HMI. When
this is enabled and i see a frequesnt timeout for the time critical RT
thread_1. Even if this image transfer is not enabled then also i see
Kernel Oops after long time, say 1 day.
All data is flowing on ethernet.
I had increaed the KSOFTIRQD policy and priority to be more than my
time critical application , but it didn't help much. Now i am trying
to understand the debug traces generated to know where the latency is
coming from.
Any suggestions is greatly appreciated.
Regards
Ashoka. K
On Mon, May 20, 2013 at 12:32 AM, Android Techies
<android.techies@gmail.com> wrote:
> Hello Ashoka,
> You can try to measure the hrtimer latency and see whether there is a delay
> in hrtimer itself. I will suggest to try and make Oprofile working. If you
> have already figured out a way please let me know as well as I need similar
> stuff.
>
>
>
> On Tue, Apr 30, 2013 at 1:27 AM, Ashoka K <ashok.vinu@gmail.com> wrote:
>>
>> Hi,
>>
>> I have an embedded system running 2.6.33 cross compiled for ARM OMAP
>> with 1 GHZ uni-processor system.
>>
>> The application has many threads and processes (around 15 total). In
>> that 1 thread is time critical and must run every interval confiurable
>> as 2, 4 or 8 milli sec etc. There is another thread which transfers
>> Images to a FTP or to HMI etc, whoever requested the image.
>> With this image transfer enabled my critical process misses the
>> deadline and timesout. This critical thread is at RR priority 50. I
>> used a HR timer thread with RR pri 55 to wakeup the critical thread
>> every 1 milli sec to do the job.
>> If image transfer is enabled i see that real time thread misses deadlines.
>>
>> All traffic is flowing on common ethernet connection. Does it affect
>> in any way ?
>>
>> How to find out where the kernel is waiting or delaying to schedule
>> the critical thread even though it is at higher RR priority. How to
>> measure the latency ?
>>
>> I am trying to use Oprofile tool, but got some error in cross
>> compiling. Doesn't these tools add their own latency to the original
>> problem ?
>>
>> Any tools ? which one is better. Please provide your input on this.
>>
>>
>> Regards
>> Ashoka. K
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
>>
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.linux-learn.org/faqs
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* RE: [systemd-devel] 2013 Plumber's CFP: Fastboot
From: Mehaffey, John @ 2013-05-16 15:03 UTC (permalink / raw)
To: Lennart Poettering
Cc: Lucas De Marchi, Jeremiah Foster,
systemd-devel@lists.freedesktop.org, wd@denx.de,
linux-embedded@vger.kernel.org, Kay.Sievers@vrfy.org,
linux-kernel@vger.kernel.org, u-boot@lists.denx.de,
tim.bird@am.sony.com, genivi-dev@mail.genivi.org,
celinux-dev@lists.celinuxforum.org, Pomerantz, Brian,
yoush@cs.msu.su
In-Reply-To: <20130516123301.GA20195@tango.0pointer.de>
> From: Lennart Poettering [mzxreary@0pointer.de]
> Sent: Thursday, May 16, 2013 5:33 AM
> On Wed, 15.05.13 15:01, Mehaffey, John (John_Mehaffey@mentor.com) wrote:
>
> > > What if we merge the proposals?
> > >
> > > John, are you ok with proposing (some of) these topics in the "Boot
> > > and Core OS" track? I could help with the module-related part, too.
> > >
> > >
> > > Lucas De Marchi
> >
> > Hi Lucas, Lennart,
> > I am fine with merging the two boot related sessions. I did not want to have it be a topic in the automotive microconf, as I believe there is enough material for a couple of hours on fastboot alone.
> >
> > It was not clear to me what topics might be in the boot and core os microconf, so I proposed fastboot as separate.
>
> Let's merge this then (the LPC guys want this to).
>
> We could copy the stuff from the fastboot MC wiki page into the
> boot/core OS wiki page, or the other way round. And preference? I'd
> still call this "Boot and Core OS MC" as this has the slightler broader
> topic, I guess...
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
Hi Lennart,
I have merged the topics from the fastboot proposal to the Boot and Core OS proposal.
Please take a look and make any improvements.
I am keeping the fastboot proposal on the wiki as reference material for now, but I have linked it to the Boot and Core OS page.
-mehaf
^ permalink raw reply
* Re: [systemd-devel] 2013 Plumber's CFP: Fastboot
From: Lennart Poettering @ 2013-05-16 12:33 UTC (permalink / raw)
To: Mehaffey, John
Cc: Lucas De Marchi, Jeremiah Foster,
systemd-devel@lists.freedesktop.org, wd@denx.de,
linux-embedded@vger.kernel.org, Kay.Sievers@vrfy.org,
linux-kernel@vger.kernel.org, u-boot@lists.denx.de,
tim.bird@am.sony.com, genivi-dev@mail.genivi.org,
celinux-dev@lists.celinuxforum.org, Pomerantz, Brian,
yoush@cs.msu.su
In-Reply-To: <371E240E6FC1D44DA5E51EE9DCDCB7845E3D32D3@NA-MBX-03.mgc.mentorg.com>
On Wed, 15.05.13 15:01, Mehaffey, John (John_Mehaffey@mentor.com) wrote:
> > What if we merge the proposals?
> >
> > John, are you ok with proposing (some of) these topics in the "Boot
> > and Core OS" track? I could help with the module-related part, too.
> >
> >
> > Lucas De Marchi
>
> Hi Lucas, Lennart,
> I am fine with merging the two boot related sessions. I did not want to have it be a topic in the automotive microconf, as I believe there is enough material for a couple of hours on fastboot alone.
>
> It was not clear to me what topics might be in the boot and core os microconf, so I proposed fastboot as separate.
Let's merge this then (the LPC guys want this to).
We could copy the stuff from the fastboot MC wiki page into the
boot/core OS wiki page, or the other way round. And preference? I'd
still call this "Boot and Core OS MC" as this has the slightler broader
topic, I guess...
Lennart
--
Lennart Poettering - Red Hat, Inc.
^ permalink raw reply
* RE: [systemd-devel] 2013 Plumber's CFP: Fastboot
From: Mehaffey, John @ 2013-05-15 15:01 UTC (permalink / raw)
To: Lucas De Marchi, Lennart Poettering
Cc: Jeremiah Foster, systemd-devel@lists.freedesktop.org, wd@denx.de,
linux-embedded@vger.kernel.org, Kay.Sievers@vrfy.org,
linux-kernel@vger.kernel.org, u-boot@lists.denx.de,
tim.bird@am.sony.com, genivi-dev@mail.genivi.org,
celinux-dev@lists.celinuxforum.org, Pomerantz, Brian,
yoush@cs.msu.su
In-Reply-To: <CAKi4VA+ru8_h=NW_X49GNL06XinsboM_ZicD8Js73Mw7x-xphA@mail.gmail.com>
> From: Lucas De Marchi [lucas.de.marchi@gmail.com]
> Sent: Wednesday, May 15, 2013 7:04 AM
>
> On Wed, May 15, 2013 at 9:50 AM, Lennart Poettering
> <mzxreary@0pointer.de> wrote:
> > On Wed, 15.05.13 11:43, Jeremiah Foster (jeremiah.foster@pelagicore.com) wrote:
> >
> >> On Tue, May 14, 2013 at 1:51 AM, Mehaffey, John <John_Mehaffey@mentor.com>wrote:
> >>
> >> > Hello All,
> >> >
> >>
> >> Hey John!
> >>
> >>
> >> > I am proposing a microconference on fastboot at the Linux Plumber's
> >> > conference 2013 in New Orleans. The goal is to get to sub 1S boot times for
> >> > a large (IVI) system using NAND flash. This pushes the state of the art,
> >> > and will require innovative solutions in may areas of Linux plumbing,
> >> > including bootloader, kernel init, UBI, and systemd.
> >> >
> >> > Note that fastboot improvements will (generally) help all architectures so
> >> > I am not limiting this to automotive systems.
> >> >
> >> > Please visit http://wiki.linuxplumbersconf.org/2013:fastboot for more
> >> > information or if you want to submit a topic.
> >> >
> >>
> >> I've linked to your micrconference from the automotive microconference:
> >> http://wiki.linuxplumbersconf.org/2013:automotive
> >>
> >> I'm a bit confused about the LPC format though. John, is it planned to have
> >> the non-Android fastboot discussion as part of the automotive
> >> microconference or is this separate (despite its automotive relevance.) I
> >> ask because it might be nice to have the participants in both
> >> microconferences and it would be a shame to lose attendees to one or the
> >> other if they're competing tracks.
> >>
> >> Can someone clue me in to the microconference format as regards LPC?
> >
> >
> > BTW, there's also this MC we proposed:
> >
> > http://wiki.linuxplumbersconf.org/2013:boot_and_core_os
> >
> > which sounds pretty close to fastboot?
> >
>
> What if we merge the proposals?
>
> John, are you ok with proposing (some of) these topics in the "Boot
> and Core OS" track? I could help with the module-related part, too.
>
>
> Lucas De Marchi
Hi Lucas, Lennart,
I am fine with merging the two boot related sessions. I did not want to have it be a topic in the automotive microconf, as I believe there is enough material for a couple of hours on fastboot alone.
It was not clear to me what topics might be in the boot and core os microconf, so I proposed fastboot as separate.
Jeremiah, you bring up a good point about overlapping interest, probably when a proposal is accepted, we will need to point out potential scheduling conflicts with other accepted microconfs to the program committee.
Sincerely,
John Mehaffey
Senior System Architect (Automotive)
Mentor Graphics Corporation
^ permalink raw reply
* Re: 2013 Plumber's CFP: Fastboot
From: Jeremiah Foster @ 2013-05-15 14:50 UTC (permalink / raw)
To: Lucas De Marchi
Cc: systemd-devel@lists.freedesktop.org, wd@denx.de,
linux-embedded@vger.kernel.org, Kay.Sievers@vrfy.org,
linux-kernel@vger.kernel.org, u-boot@lists.denx.de,
Lennart Poettering, tim.bird@am.sony.com,
genivi-dev@mail.genivi.org, celinux-dev@lists.celinuxforum.org,
Pomerantz, Brian, yoush@cs.msu.su
In-Reply-To: <CAKi4VA+ru8_h=NW_X49GNL06XinsboM_ZicD8Js73Mw7x-xphA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1592 bytes --]
On Wed, May 15, 2013 at 4:04 PM, Lucas De Marchi
<lucas.de.marchi@gmail.com>wrote:
> On Wed, May 15, 2013 at 9:50 AM, Lennart Poettering
> <mzxreary@0pointer.de> wrote:
> > On Wed, 15.05.13 11:43, Jeremiah Foster (jeremiah.foster@pelagicore.com)
> wrote:
> >
> >> On Tue, May 14, 2013 at 1:51 AM, Mehaffey, John <
> John_Mehaffey@mentor.com>wrote:
> >>
> >> > Please visit http://wiki.linuxplumbersconf.org/2013:fastboot for more
> >> > information or if you want to submit a topic.
> >> >
> >>
> >> I've linked to your micrconference from the automotive microconference:
> >> http://wiki.linuxplumbersconf.org/2013:automotive
> >>
> >> I'm a bit confused about the LPC format though. John, is it planned to
> have
> >> the non-Android fastboot discussion as part of the automotive
> >> microconference or is this separate (despite its automotive relevance.)
> I
> >> ask because it might be nice to have the participants in both
> >> microconferences and it would be a shame to lose attendees to one or the
> >> other if they're competing tracks.
> >>
> >> Can someone clue me in to the microconference format as regards LPC?
> >
> >
> > BTW, there's also this MC we proposed:
> >
> > http://wiki.linuxplumbersconf.org/2013:boot_and_core_os
> >
> > which sounds pretty close to fastboot?
> >
>
> What if we merge the proposals?
>
+1
>
> John, are you ok with proposing (some of) these topics in the "Boot
> and Core OS" track? I could help with the module-related part, too.
A merge would help with attendance I believe, without significantly hurting
topic coverage.
Cheers,
Jeremiah
[-- Attachment #1.2: Type: text/html, Size: 2841 bytes --]
[-- Attachment #2: Type: text/plain, Size: 171 bytes --]
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox