2009-01-09 15:07:25

by Arjan van de Ven

[permalink] [raw]
Subject: Partially defer some of the async stuff to the next release

Hi Linus,

I think it's better that we defer some of the asynchronous boot stuff to
2.6.30 so that it can bake in -next for a bit. I would like to keep the
core infrastructure in place for 29, so that the various subsystem
patches etc can just use it in -next without generating dependencies in
the patch flow.

for both libata and the inode delete very simple things can be done to
fix them, but I would feel a lot more comfortable giving these a ride
in -next.


The following changes since commit
2150edc6c5cf00f7adb54538b9ea2a3e9cedca3f: Linus Torvalds (1):
Merge branch 'for_linus' of git://git.kernel.org/.../tytso/ext4

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-undo.git
master

Arjan van de Ven (3):
Revert "fastboot: Make libata initialization even more async"
Revert "fastboot: make the libata port scan asynchronous"
partial revert of asynchronous inode delete

drivers/ata/libata-core.c | 96
+++++++++++++++++++++------------------------
fs/inode.c | 19 +++------ 2 files changed, 51
insertions(+), 64 deletions(-)


--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org


2009-01-09 20:43:34

by Linus Torvalds

[permalink] [raw]
Subject: Re: Partially defer some of the async stuff to the next release



On Fri, 9 Jan 2009, Arjan van de Ven wrote:
>
> I think it's better that we defer some of the asynchronous boot stuff to
> 2.6.30 so that it can bake in -next for a bit. I would like to keep the
> core infrastructure in place for 29, so that the various subsystem
> patches etc can just use it in -next without generating dependencies in
> the patch flow.
>
> for both libata and the inode delete very simple things can be done to
> fix them, but I would feel a lot more comfortable giving these a ride
> in -next.

Can we rather make this something that people can enable with a "fastboot"
option and is disabled by default? At least that way the ATA people can
see the problem, and don't just forget about it, since we want it fixed.

Linus

2009-01-09 20:51:34

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Partially defer some of the async stuff to the next release

On Fri, 9 Jan 2009 12:42:34 -0800 (PST)
Linus Torvalds <[email protected]> wrote:

>
>
> On Fri, 9 Jan 2009, Arjan van de Ven wrote:
> >
> > I think it's better that we defer some of the asynchronous boot
> > stuff to 2.6.30 so that it can bake in -next for a bit. I would
> > like to keep the core infrastructure in place for 29, so that the
> > various subsystem patches etc can just use it in -next without
> > generating dependencies in the patch flow.
> >
> > for both libata and the inode delete very simple things can be done
> > to fix them, but I would feel a lot more comfortable giving these a
> > ride in -next.
>
> Can we rather make this something that people can enable with a
> "fastboot" option and is disabled by default? At least that way the
> ATA people can see the problem, and don't just forget about it, since
> we want it fixed.

ok sure, that's not hard. I'll get that going, hopefully before the end
of the day



--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org

2009-01-09 21:22:09

by Alan

[permalink] [raw]
Subject: Re: Partially defer some of the async stuff to the next release

> Can we rather make this something that people can enable with a "fastboot"
> option and is disabled by default? At least that way the ATA people can
> see the problem, and don't just forget about it, since we want it fixed.

Makes some sense - although the inode one should just take a hike at this
point. Can the fastboot option live under staging perhaps - its analogous
to staging drivers although clearly the code doesn't go there in this
case ?

The trouble otherwise is "fast boot" sounds like something good for
people to turn on, but right now it's the reverse.

Alan

2009-01-09 21:29:18

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Partially defer some of the async stuff to the next release

On Fri, 9 Jan 2009 21:22:01 +0000
Alan Cox <[email protected]> wrote:

> > Can we rather make this something that people can enable with a
> > "fastboot" option and is disabled by default? At least that way the
> > ATA people can see the problem, and don't just forget about it,
> > since we want it fixed.
>
> Makes some sense - although the inode one should just take a hike at
> this point. Can the fastboot option live under staging perhaps - its
> analogous to staging drivers although clearly the code doesn't go
> there in this case ?
>
> The trouble otherwise is "fast boot" sounds like something good for
> people to turn on, but right now it's the reverse.

I just coded it as a kernel command line option only

that's very much a "I know what I'm doing" kind of thng.


--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org

2009-01-09 21:31:22

by David Lang

[permalink] [raw]
Subject: Re: Partially defer some of the async stuff to the next release

On Fri, 9 Jan 2009, Alan Cox wrote:

>> Can we rather make this something that people can enable with a "fastboot"
>> option and is disabled by default? At least that way the ATA people can
>> see the problem, and don't just forget about it, since we want it fixed.
>
> Makes some sense - although the inode one should just take a hike at this
> point. Can the fastboot option live under staging perhaps - its analogous
> to staging drivers although clearly the code doesn't go there in this
> case ?
>
> The trouble otherwise is "fast boot" sounds like something good for
> people to turn on, but right now it's the reverse.

isn't this like OPTIMIZE_INLINE?

David Lang

2009-01-09 21:52:22

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Partially defer some of the async stuff to the next release

On Fri, 9 Jan 2009 12:42:34 -0800 (PST)
Linus Torvalds <[email protected]> wrote:

>
>
> On Fri, 9 Jan 2009, Arjan van de Ven wrote:
> >
> > I think it's better that we defer some of the asynchronous boot
> > stuff to 2.6.30 so that it can bake in -next for a bit. I would
> > like to keep the core infrastructure in place for 29, so that the
> > various subsystem patches etc can just use it in -next without
> > generating dependencies in the patch flow.
> >
> > for both libata and the inode delete very simple things can be done
> > to fix them, but I would feel a lot more comfortable giving these a
> > ride in -next.
>
> Can we rather make this something that people can enable with a
> "fastboot" option and is disabled by default? At least that way the
> ATA people can see the problem, and don't just forget about it, since
> we want it fixed.


if you pull this you get the patch that removes the inode part for now,
and adds a "fastboot" kernel commandline option to enable the async
behavior.


The following changes since commit
7c51d57e9d7fbce89f79c41dc8da383101dbe9c6: Linus Torvalds (1):
Merge git://git.infradead.org/mtd-2.6

are available in the git repository at:

ssh://master.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-2
master

Arjan van de Ven (2):
partial revert of asynchronous inode delete
async: make async a command line option for now

fs/inode.c | 19 +++++++------------
kernel/async.c | 16 ++++++++++++++--
2 files changed, 21 insertions(+), 14 deletions(-)




--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org