On 30/03/2005 10:45:55 linux-kernel-owner wrote:
>> The solution is fairly well known. Rather than treating the zillions
of
>> disk seeks during the boot process as random unconnected events, you
>
>Heh, we actually tried that at SuSE and yes, eliminating seeks helps a
>bit, but no, it is not
Hi!
> > > I'm really not trolling, but I suspect if we made the boot process less
> > > verbose, people would start to wonder more about why Linux takes so much
> > > longer than XP to boot.
> >
> > By the way, Microsoft seems to be claiming that boot time will be reduced
> > to the half
> >
Hi!
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would start to wonder more about why Linux takes so much
longer than XP to boot.
By the way, Microsoft seems to be claiming that boot time will be reduced
to the half
with Longhorn.
On 30/03/2005 10:45:55 linux-kernel-owner wrote:
The solution is fairly well known. Rather than treating the zillions
of
disk seeks during the boot process as random unconnected events, you
Heh, we actually tried that at SuSE and yes, eliminating seeks helps a
bit, but no, it is not magicall
On Wed, Mar 23, 2005 at 05:49:47PM +0100, Giuseppe Bilotta wrote:
> > > What are the cons of using "all of" the RAM at boot time to
> > > cache the boot disk?
>
> Dave Jones wrote:
> > It's memory that's otherwise unused. Once you start using the system
> > anything cached will get
> > What are the cons of using "all of" the RAM at boot time to
> > cache the boot disk?
Dave Jones wrote:
> It's memory that's otherwise unused. Once you start using the system
> anything cached will get reclaimed as its needed.
So there is no substantial loss? IOW, it would suffice to have
On Wed, Mar 23, 2005 at 09:21:22AM +0100, Giuseppe Bilotta wrote:
> Dave Jones wrote:
> > Some of the folks on our desktop team have been doing a bunch of
> > experiments
> > at getting boot times down, including laying out the blocks in a more
> > optimal manner, allowing /sbin/readahead to
El Tue, 22 Mar 2005 20:13:15 -0500,
Dave Jones <[EMAIL PROTECTED]> escribió:
> With something like this, and some additional bookkeeping to keep track of
> which files we open in the first few minutes of uptime, we could periodically
> reorganise the layout back to an optimal state.
That
Lee Revell wrote:
> Yup, many people on this list seem unaware but read the XP white papers,
> then try booting it side by side with Linux. They put some serious,
> serious engineering into that problem and came out with a big win.
> Screw Longhorn, we need improve by 50% to catch up to what they
Dave Jones wrote:
> Some of the folks on our desktop team have been doing a bunch of experiments
> at getting boot times down, including laying out the blocks in a more
> optimal manner, allowing /sbin/readahead to slurp the data off the disk
> in one big chunk, and run almost entirely from cache.
Dave Jones wrote:
Some of the folks on our desktop team have been doing a bunch of experiments
at getting boot times down, including laying out the blocks in a more
optimal manner, allowing /sbin/readahead to slurp the data off the disk
in one big chunk, and run almost entirely from cache.
Lee Revell wrote:
Yup, many people on this list seem unaware but read the XP white papers,
then try booting it side by side with Linux. They put some serious,
serious engineering into that problem and came out with a big win.
Screw Longhorn, we need improve by 50% to catch up to what they can
El Tue, 22 Mar 2005 20:13:15 -0500,
Dave Jones [EMAIL PROTECTED] escribió:
With something like this, and some additional bookkeeping to keep track of
which files we open in the first few minutes of uptime, we could periodically
reorganise the layout back to an optimal state.
That wouldn't be
On Wed, Mar 23, 2005 at 09:21:22AM +0100, Giuseppe Bilotta wrote:
Dave Jones wrote:
Some of the folks on our desktop team have been doing a bunch of
experiments
at getting boot times down, including laying out the blocks in a more
optimal manner, allowing /sbin/readahead to slurp
What are the cons of using all of the RAM at boot time to
cache the boot disk?
Dave Jones wrote:
It's memory that's otherwise unused. Once you start using the system
anything cached will get reclaimed as its needed.
So there is no substantial loss? IOW, it would suffice to have
all the
On Wed, Mar 23, 2005 at 05:49:47PM +0100, Giuseppe Bilotta wrote:
What are the cons of using all of the RAM at boot time to
cache the boot disk?
Dave Jones wrote:
It's memory that's otherwise unused. Once you start using the system
anything cached will get reclaimed as its
Dave Jones <[EMAIL PROTECTED]> wrote:
>
> This old mail: http://marc.free.net.ph/message/20040304.030616.59761bf3.html
> references a 'move block' ioctl, which is probably the hardest part of the
> problem,
> though I didn't find the code referenced in that mail. Andrew ?
That would be
On Tue, Mar 22, 2005 at 07:53:37PM -0500, Lee Revell wrote:
> The solution is fairly well known. Rather than treating the zillions of
> disk seeks during the boot process as random unconnected events, you
> analyze the I/O done during the boot process, then lay out those disk
> blocks
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote:
> El Mon, 14 Mar 2005 14:07:53 -0500,
> Lee Revell <[EMAIL PROTECTED]> escribió:
>
> > I'm really not trolling, but I suspect if we made the boot process less
> > verbose, people would start to wonder more about why Linux takes so much
> >
On Wed, 23 Mar 2005 01:37:29 +0100, Diego Calleja <[EMAIL PROTECTED]> wrote:
>El Mon, 14 Mar 2005 14:07:53 -0500,
>Lee Revell <[EMAIL PROTECTED]> escribió:
>
>> I'm really not trolling, but I suspect if we made the boot process less
>> verbose, people would start to wonder more about why Linux
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote:
> El Mon, 14 Mar 2005 14:07:53 -0500,
> Lee Revell <[EMAIL PROTECTED]> escribió:
>
> > I'm really not trolling, but I suspect if we made the boot process less
> > verbose, people would start to wonder more about why Linux takes so much
> >
El Mon, 14 Mar 2005 14:07:53 -0500,
Lee Revell <[EMAIL PROTECTED]> escribió:
> I'm really not trolling, but I suspect if we made the boot process less
> verbose, people would start to wonder more about why Linux takes so much
> longer than XP to boot.
By the way, Microsoft seems to be claiming
El Mon, 14 Mar 2005 14:07:53 -0500,
Lee Revell [EMAIL PROTECTED] escribió:
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would start to wonder more about why Linux takes so much
longer than XP to boot.
By the way, Microsoft seems to be claiming that
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote:
El Mon, 14 Mar 2005 14:07:53 -0500,
Lee Revell [EMAIL PROTECTED] escribió:
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would start to wonder more about why Linux takes so much
longer than
On Wed, 23 Mar 2005 01:37:29 +0100, Diego Calleja [EMAIL PROTECTED] wrote:
El Mon, 14 Mar 2005 14:07:53 -0500,
Lee Revell [EMAIL PROTECTED] escribió:
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would start to wonder more about why Linux takes so much
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote:
El Mon, 14 Mar 2005 14:07:53 -0500,
Lee Revell [EMAIL PROTECTED] escribió:
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would start to wonder more about why Linux takes so much
longer than
On Tue, Mar 22, 2005 at 07:53:37PM -0500, Lee Revell wrote:
The solution is fairly well known. Rather than treating the zillions of
disk seeks during the boot process as random unconnected events, you
analyze the I/O done during the boot process, then lay out those disk
blocks optimally
Dave Jones [EMAIL PROTECTED] wrote:
This old mail: http://marc.free.net.ph/message/20040304.030616.59761bf3.html
references a 'move block' ioctl, which is probably the hardest part of the
problem,
though I didn't find the code referenced in that mail. Andrew ?
That would be
On Mon, 14 Mar 2005, Lee Revell wrote:
On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote:
Why should people look at all that "horrid" debug info everytime
they boot, except when they have a problem?
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would
On Mon, 14 Mar 2005, Lee Revell wrote:
On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote:
Why should people look at all that horrid debug info everytime
they boot, except when they have a problem?
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would
Linus Torvalds <[EMAIL PROTECTED]> writes:
> And those occasional people are often not going to eb very good at
> reporting bugs. If they don't see anything happening, they'll just give up
> rather than bother to report it. So I do think we want the fairly verbose
> thing enabled by default. You
Linus Torvalds [EMAIL PROTECTED] writes:
And those occasional people are often not going to eb very good at
reporting bugs. If they don't see anything happening, they'll just give up
rather than bother to report it. So I do think we want the fairly verbose
thing enabled by default. You can
Hi!
> > We already have the 'quiet' option, but even so, I think the kernel is
> > *way*
> > too verbose. Someone needs to make a personal crusade out of removing
> > unneeded and unjustified printks from the kernel before it really gets
> > better
> > though...
>
> Oh well, I admit going
On Tue, 15 Mar 2005, Benjamin Herrenschmidt wrote:
We already have the 'quiet' option, but even so, I think the kernel is *way*
too verbose. Someone needs to make a personal crusade out of removing
unneeded and unjustified printks from the kernel before it really gets better
though...
Oh well, I
> We already have the 'quiet' option, but even so, I think the kernel is *way*
> too verbose. Someone needs to make a personal crusade out of removing
> unneeded and unjustified printks from the kernel before it really gets better
> though...
Oh well, I admit going backward here with my new
[trimming cc list in case this starts a flame war)
On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote:
> Why should people look at all that "horrid" debug info everytime
> they boot, except when they have a problem?
I'm really not trolling, but I suspect if we made the boot process less
El Mon, 14 Mar 2005 08:55:18 -0800,
Jesse Barnes <[EMAIL PROTECTED]> escribió:
> We already have the 'quiet' option, but even so, I think the kernel is *way*
> too verbose. Someone needs to make a personal crusade out of removing
> unneeded and unjustified printks from the kernel before it
Hi!
> > We already have the 'quiet' option, but even so, I think the kernel is
> > *way*
> > too verbose. Someone needs to make a personal crusade out of removing
> > unneeded and unjustified printks from the kernel before it really gets
> > better
> > though...
>
> The thing is, this
On Monday, March 14, 2005 9:18 am, Linus Torvalds wrote:
> In fact, even the ones that have no "information" end up often being a big
> clue about where the hang happened.
Yeah, I use the startup output all the time for stuff like that, no question
it's useful.
> And those occasional people are
On Mon, Mar 14, 2005 at 08:55:18AM -0800, Jesse Barnes wrote:
> On Monday, March 14, 2005 12:37 am, Pavel Machek wrote:
> > Perhaps we could have a rule like
> >
> > "non-experimental driver may only print out one line per actual
> > device?"
> >
> > (and perhaps: dmesg output for boot
On Mon, 14 Mar 2005, Jesse Barnes wrote:
>
> We already have the 'quiet' option, but even so, I think the kernel is *way*
> too verbose. Someone needs to make a personal crusade out of removing
> unneeded and unjustified printks from the kernel before it really gets better
> though...
The
Hi!
> > "non-experimental driver may only print out one line per actual
> > device?"
> >
> > (and perhaps: dmesg output for boot going okay should fit on one screen).
> >
> > Or perhaps we should have warnings-like regression testing.
> >
> > "New kernel 2.8.17 came: 3 errors, 135 warnings, 1890
On Monday, March 14, 2005 12:37 am, Pavel Machek wrote:
> Perhaps we could have a rule like
>
> "non-experimental driver may only print out one line per actual
> device?"
>
> (and perhaps: dmesg output for boot going okay should fit on one screen).
>
> Or perhaps we should have warnings-like
On Monday, March 14, 2005 12:37 am, Pavel Machek wrote:
Perhaps we could have a rule like
non-experimental driver may only print out one line per actual
device?
(and perhaps: dmesg output for boot going okay should fit on one screen).
Or perhaps we should have warnings-like regression
Hi!
non-experimental driver may only print out one line per actual
device?
(and perhaps: dmesg output for boot going okay should fit on one screen).
Or perhaps we should have warnings-like regression testing.
New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg
On Mon, 14 Mar 2005, Jesse Barnes wrote:
We already have the 'quiet' option, but even so, I think the kernel is *way*
too verbose. Someone needs to make a personal crusade out of removing
unneeded and unjustified printks from the kernel before it really gets better
though...
The thing
On Mon, Mar 14, 2005 at 08:55:18AM -0800, Jesse Barnes wrote:
On Monday, March 14, 2005 12:37 am, Pavel Machek wrote:
Perhaps we could have a rule like
non-experimental driver may only print out one line per actual
device?
(and perhaps: dmesg output for boot going okay should
On Monday, March 14, 2005 9:18 am, Linus Torvalds wrote:
In fact, even the ones that have no information end up often being a big
clue about where the hang happened.
Yeah, I use the startup output all the time for stuff like that, no question
it's useful.
And those occasional people are
Hi!
We already have the 'quiet' option, but even so, I think the kernel is
*way*
too verbose. Someone needs to make a personal crusade out of removing
unneeded and unjustified printks from the kernel before it really gets
better
though...
The thing is, this comes up every
El Mon, 14 Mar 2005 08:55:18 -0800,
Jesse Barnes [EMAIL PROTECTED] escribió:
We already have the 'quiet' option, but even so, I think the kernel is *way*
too verbose. Someone needs to make a personal crusade out of removing
unneeded and unjustified printks from the kernel before it really
[trimming cc list in case this starts a flame war)
On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote:
Why should people look at all that horrid debug info everytime
they boot, except when they have a problem?
I'm really not trolling, but I suspect if we made the boot process less
verbose,
We already have the 'quiet' option, but even so, I think the kernel is *way*
too verbose. Someone needs to make a personal crusade out of removing
unneeded and unjustified printks from the kernel before it really gets better
though...
Oh well, I admit going backward here with my new
On Tue, 15 Mar 2005, Benjamin Herrenschmidt wrote:
We already have the 'quiet' option, but even so, I think the kernel is *way*
too verbose. Someone needs to make a personal crusade out of removing
unneeded and unjustified printks from the kernel before it really gets better
though...
Oh well, I
Hi!
We already have the 'quiet' option, but even so, I think the kernel is
*way*
too verbose. Someone needs to make a personal crusade out of removing
unneeded and unjustified printks from the kernel before it really gets
better
though...
Oh well, I admit going backward here
54 matches
Mail list logo
