From: Surbhi Palande <surbhi.palande@canonical.com>

The expansion of the initramfs is completely independant of other
boot activities. The original data is already present at boot and the
filesystem is not required until we are ready to start init. It is
therefore reasonable to populate the rootfs asynchronously. Move this
processing to an async call.

Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
include/linux/init.h | 2 ++
init/initramfs.c | 15 ++++++++++++---
init/main.c | 6 ++++++
3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index ff8bde5..b57935f 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -213,6 +213,8 @@ extern void (*late_time_init)(void);
static initcall_t __initcall_##fn
__used __section(.security_initcall.init) = fn

+extern struct list_head populate_rootfs_domain;
+
struct obs_kernel_param {
const char *str;
int (*setup_func)(char *);
diff --git a/init/initramfs.c b/init/initramfs.c
index 4c00edc..b8f9e3c 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -8,6 +8,7 @@
#include <linux/dirent.h>
#include <linux/syscalls.h>
#include <linux/utime.h>
+#include <linux/async.h>

static __initdata char *message;
static void __init error(char *x)
@@ -565,7 +566,9 @@ static void __init clean_rootfs(void)
}
#endif

-static int __init populate_rootfs(void)
+LIST_HEAD(populate_rootfs_domain);
+
+static void __init async_populate_rootfs(void)
{
char *err = unpack_to_rootfs(__initramfs_start,
__initramfs_end - __initramfs_start);
@@ -579,7 +582,7 @@ static int __init populate_rootfs(void)
initrd_end - initrd_start);
if (!err) {
free_initrd();
- return 0;
+ return;
} else {
clean_rootfs();
unpack_to_rootfs(__initramfs_start,
@@ -603,6 +606,12 @@ static int __init populate_rootfs(void)
free_initrd();
#endif
}
- return 0;
+ return;
}
+
+static int __init populate_rootfs(void)
+{
+ async_schedule_domain(async_populate_rootfs, NULL, &populate_rootfs_domain);
+}
+
rootfs_initcall(populate_rootfs);
diff --git a/init/main.c b/init/main.c
index 21d8a05..174abe4 100644
--- a/init/main.c
+++ b/init/main.c
@@ -879,6 +879,12 @@ static int __init kernel_init(void * unused)
do_basic_setup();

/*
+ * We need to ensure that the filesystem is ready by this point, wait for
+ * async_populate_rootfs to complete.
+ */
+ async_synchronize_full_domain(&populate_rootfs_dom ain);
+
+ /*
* check if there is an early userspace init. If yes, let it do all
* the work
*/
--
1.6.3.3


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Andy Whitcroft wrote:
> From: Surbhi Palande <surbhi.palande@canonical.com>
>
> The expansion of the initramfs is completely independant of other
> boot activities. The original data is already present at boot and the
> filesystem is not required until we are ready to start init. It is
> therefore reasonable to populate the rootfs asynchronously. Move this
> processing to an async call.
>
> Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
> Signed-off-by: Andy Whitcroft <apw@canonical.com>

Perhaps the commit log message should also describe _why_ we're applying
this patch, e.g., it improves boot performance on a wide range of
multi-core CPU's without adversely impacting single core CPUs (or
something like that). You know we'll get that question as soon as we try
upstreaming it.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Wed, 2009-12-09 at 09:41 -0700, Tim Gardner wrote:

> Perhaps the commit log message should also describe _why_ we're applying
> this patch, e.g., it improves boot performance on a wide range of
> multi-core CPU's without adversely impacting single core CPUs (or
> something like that). You know we'll get that question as soon as we try
> upstreaming it.
>
It improves boot performance of single core too, no? (e.g. Atom N270 in
those Mini 10vs)

Scott
--
Scott James Remnant
scott@ubuntu.com
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Scott James Remnant wrote:
> On Wed, 2009-12-09 at 09:41 -0700, Tim Gardner wrote:
>
>> Perhaps the commit log message should also describe _why_ we're applying
>> this patch, e.g., it improves boot performance on a wide range of
>> multi-core CPU's without adversely impacting single core CPUs (or
>> something like that). You know we'll get that question as soon as we try
>> upstreaming it.
>>
> It improves boot performance of single core too, no? (e.g. Atom N270 in
> those Mini 10vs)
>
> Scott

Ok, non-hyperthreaded single core CPUs.

--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Wed, Dec 09, 2009 at 09:55:58AM -0700, Tim Gardner wrote:
> Scott James Remnant wrote:
> > On Wed, 2009-12-09 at 09:41 -0700, Tim Gardner wrote:
> >
> >> Perhaps the commit log message should also describe _why_ we're applying
> >> this patch, e.g., it improves boot performance on a wide range of
> >> multi-core CPU's without adversely impacting single core CPUs (or
> >> something like that). You know we'll get that question as soon as we try
> >> upstreaming it.
> >>
> > It improves boot performance of single core too, no? (e.g. Atom N270 in
> > those Mini 10vs)
> >
> > Scott
>
> Ok, non-hyperthreaded single core CPUs.

Generally even those as long as its not started early. The cpu
consumption overlaps with the port probes to good effect. Not as good
as on the netbooks but noticable.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team