Partially defer some of the async stuff to the next release

Partially defer some of the async stuff to the next release

[Arjan van de Ven]

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

Re: Partially defer some of the async stuff to the next release

[Linus Torvalds]

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

Re: Partially defer some of the async stuff to the next release

[Arjan van de Ven]

On Fri, 9 Jan 2009 12:42:34 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> 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

Re: Partially defer some of the async stuff to the next release

[Alan Cox]

> 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

Re: Partially defer some of the async stuff to the next release

[Arjan van de Ven]

On Fri, 9 Jan 2009 21:22:01 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> 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

Re: Partially defer some of the async stuff to the next release

[david]

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

Re: Partially defer some of the async stuff to the next release

[Arjan van de Ven]

On Fri, 9 Jan 2009 12:42:34 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> 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