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 ma
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
> > wit
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 reclaime
> > 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
al
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 wouldn't
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 <[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 http://
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 optimal
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
> > lo
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 tak
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
> > lo
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 th
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 s
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
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 b
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 a
> 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 r
[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
verbo
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 real
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
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 going
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 t
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 l
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 regres
Hi!
> >>I'm fascinated that not a single person picked up on this problem
> >>whilst the agp code sat in -mm. Even if DRI isn't enabled,
> >>every box out there with AGP that uses the generic routines
> >>(which is a majority), should have barfed loudly when it hit
> >>this check during boot. Doe
28 matches
Mail list logo
