On Wed, Oct 07 2009, Petter Reinholdtsen wrote:
> [Manoj Srivastava]
>>> Is CONCURRENCY set in /etc/init.d/rc ? I used to have it set there.
>>
>> /etc/init.d/rc:CONCURRENCY=none
>
> Could it be a bootchart problem instead, graphing the wrong file or
> something? The version in unstable was bro
[Manoj Srivastava]
>> Is CONCURRENCY set in /etc/init.d/rc ? I used to have it set there.
>
> /etc/init.d/rc:CONCURRENCY=none
Could it be a bootchart problem instead, graphing the wrong file or
something? The version in unstable was broken because some Java
library changed its API. I uploaded
On Tue, Oct 06 2009, Felipe Sateler wrote:
> On Tue, 2009-10-06 at 09:50 +0200, Petter Reinholdtsen wrote:
>> [Manoj Srivastava]
>> > I rebooted, and I still get init.d/rc is starting startpar. I do
>> > not have any line with CONCURRENCY= in /etc/default/rcS, commented
>> > or otherwise. There
On Tue, 2009-10-06 at 09:50 +0200, Petter Reinholdtsen wrote:
> [Manoj Srivastava]
> > I rebooted, and I still get init.d/rc is starting startpar. I do
> > not have any line with CONCURRENCY= in /etc/default/rcS, commented
> > or otherwise. There is definitely a bug somewhere.
>
> Very strange.
[Manoj Srivastava]
> I rebooted, and I still get init.d/rc is starting startpar. I do
> not have any line with CONCURRENCY= in /etc/default/rcS, commented
> or otherwise. There is definitely a bug somewhere.
Very strange. This do not happen when I test without the CONCURRENCY
value set. Is th
On Mon, Oct 05 2009, Manoj Srivastava wrote:
> Well, I have commented it out; I'll try again to reboot after
> removing the line.
I rebooted, and I still get init.d/rc is starting startpar. I do
not have any line with CONCURRENCY= in /etc/default/rcS, commented or
otherwise. Th
Hi,
Well, I have commented it out; I'll try again to reboot after
removing the line.
manoj
#
# /etc/default/rcS
#
# Default settings for the scripts in /etc/rcS.d/
#
# For information about these variables see the rcS(5) manual page.
#
# This file belongs to the "initscripts" pa
[Manoj Srivastava]
> ok. Late, but better than never:
> http://people.debian.org/~srivasta/
Thank you. Very interesting to see. :)
> bootchart-unopt.png = Data from before I started working
> on optimizing boot times
Duration 2 minutes 13 s
On Fri, Sep 25 2009, Petter Reinholdtsen wrote:
> [Manoj Srivastava]
>> I can still put up the bootchartd data, but it is pretty boring.
> Please do, I find it interesting to learn more how different Debian
> systems boot to see if there are new improvements to be found. :)
ok. Late, but
[Manoj Srivastava]
> So, on deeper inspection, I have to recant: setting concurrency to
> makefile in /etc/default/rcS does not in fact change the
> timing. Which made me wonder why I thought it did, and it might be
> that I removed but not purged a package, and that might have made
> inserv
On Sat, Sep 12 2009, Petter Reinholdtsen wrote:
> [Michael Biebl]
>> Would be interesting to have a before and after bootchart so this
>> regression can be investigated.
>
> Yes, definitely. Would also be interesting to know what kind of
> hardware you got (CPU, harddrive), and if you enabled read
On Sun, Sep 20, 2009 at 13:52:59 -0700, lkcl wrote:
[...]
> some years back, richard lightman wrote depinit. it's a complete
> replacement for sysvinit, and it's a parallel initialisation system.
>
> unlike sysvinit, it caught _all_ signals on applications.
>
> i installed it several times, a
remains absolutely streets
ahead of anything else i've encountered,
l.
--
View this message in context:
http://www.nabble.com/Faster-boot-by-running-init.d-scripts-in-parallel-tp25381465p25530129.html
Sent from the Debian Devel mailing list archive at Nabble.com.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Sat, Sep 12 2009, Petter Reinholdtsen wrote:
> [Michael Biebl]
>> Would be interesting to have a before and after bootchart so this
>> regression can be investigated.
>
> Yes, definitely. Would also be interesting to know what kind of
> hardware you got (CPU, harddrive), and if you enabled read
[Michael Biebl]
> Would be interesting to have a before and after bootchart so this
> regression can be investigated.
Yes, definitely. Would also be interesting to know what kind of
hardware you got (CPU, harddrive), and if you enabled readahead or
not.
Happy hacking,
--
Petter Reinholdtsen
-
Manoj Srivastava wrote:
>
> I actually lost 7 seconds, according to bootchard, by setting
> that.
Would be interesting to have a before and after bootchart so this regression can
be investigated.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe
On Fri, 11 Sep 2009, Olivier Bonvalet wrote:
> But combined with "readahead", there is no I/O bound during init.
> Most of needed files are preload.
Any initscripts that deal with devices will still be I/O bound. And the
current scheduler doesn't help (see current threads in LKML). You should
st
On Fri, Sep 11 2009, Wouter Verhelst wrote:
> On Thu, Sep 10, 2009 at 01:05:32PM +0200, Petter Reinholdtsen wrote:
>> If you want to test this feature in testing or unstable, use this
>> command:
>>
>> echo CONCURRENCY=makefile >> /etc/default/rcS
>>
>> It will enable makefile style concurrenc
Wouter Verhelst wrote:
> On Thu, Sep 10, 2009 at 01:05:32PM +0200, Petter Reinholdtsen wrote:
>> If you want to test this feature in testing or unstable, use this
>> command:
>>
>> echo CONCURRENCY=makefile >> /etc/default/rcS
>>
>> It will enable makefile style concurrency, and run N scripts in
[Wouter Verhelst]
> That seems suboptimal.
Could be. See the startpar program to see how the scripts are run in
parallel. Note that the boot is mostly CPU bound when readahead is
used, which you should use if you care about boot speed. :)
> If it actually is configurable, but you just didn't te
But combined with "readahead", there is no I/O bound during init.
Most of needed files are preload.
Wouter Verhelst a écrit :
On Thu, Sep 10, 2009 at 01:05:32PM +0200, Petter Reinholdtsen wrote:
If you want to test this feature in testing or unstable, use this
command:
echo CONCURRENCY=ma
On Thu, Sep 10, 2009 at 01:05:32PM +0200, Petter Reinholdtsen wrote:
> If you want to test this feature in testing or unstable, use this
> command:
>
> echo CONCURRENCY=makefile >> /etc/default/rcS
>
> It will enable makefile style concurrency, and run N scripts in
> parallel during boot, where
One "hidden" feature of the current Debian boot sustem, is the ability
to run the init.d scripts in parallel. This require dependency based
boot sequencing to be enabled, and the init.d script dependencies to
be complete and correct to work reliably. The feature is hidden and
undocumented, becaus
On Tue, Oct 21, 2003 at 05:08:11AM +0200, Thomas Hood wrote:
> On Tue, 2003-10-21 at 02:44, Russell Coker wrote:
> > Surely if a daemon takes a long time before it detaches from it's terminal
> > and
> > "goes daemon", then you can have a parent process put it in the background
> > and direct it
On Tue, Oct 21, 2003 at 05:08:11AM +0200, Thomas Hood wrote:
> System V initscripts must not return until the services they start are
> ready to use. Otherwise running initscript Y after initscript X from
> /etc/rc?.d/ doesn't guarantee that Y can make use of X. Providing such
> guarantees is th
Christoph Berg wrote:
I've been thinking for a while to use a Makefile for that,
the IBM article
http://www-106.ibm.com/developerworks/linux/library/l-boot.html
uses make
On Tue 10/21/03 14:44, Christoph Berg wrote:
> I've been thinking for a while to use a Makefile for that, then you get
> parallelizing for free with 'make -j'. It should be easy to set up the
> rules for starting services; stopping might be more complex (how to
> 'reverse' a Makefile?).
You could
Re: Re: faster boot [Thomas Hood <[EMAIL PROTECTED]>, Tue, Oct 21, 2003 at
05:08:11AM +0200, <[EMAIL PROTECTED]>]
> System V initscripts must not return until the services they start
> are ready to use. Otherwise running initscript Y after initscript
> X from /etc/rc?.d/ doe
On Tue, Oct 21, 2003 at 05:33:38AM +0200, Thomas Hood wrote:
> On Tue, 2003-10-21 at 05:12, Russell Coker wrote:
> > Hmm, maybe we could make it the rule that anything with number 99 can
> > return
> > before it's finished initialising?
>
> If the point here is to "speed up boot" then I think it
On Tue, 2003-10-21 at 05:12, Russell Coker wrote:
> Hmm, maybe we could make it the rule that anything with number 99 can return
> before it's finished initialising?
If the point here is to "speed up boot" then I think it would suffice
to move the rc symlinks for those "leaf" services to somethin
On Tue, 21 Oct 2003 13:08, Thomas Hood wrote:
> On Tue, 2003-10-21 at 02:44, Russell Coker wrote:
> > Surely if a daemon takes a long time before it detaches from it's
> > terminal and "goes daemon", then you can have a parent process put it in
> > the background and direct it's output to some conv
On Tue, 2003-10-21 at 02:44, Russell Coker wrote:
> Surely if a daemon takes a long time before it detaches from it's terminal
> and
> "goes daemon", then you can have a parent process put it in the background
> and direct it's output to some convenient log file.
System V initscripts must not r
On Tue, 21 Oct 2003 04:13, Mark Ferlatte wrote:
> I suspect that the improvement would be _very_ system dependent, though.
> For example, netatalk takes a _long_ time to start, and parallelizing would
> be a benefit. sendmail can take a while too, especially if you have DNS
> issues at boot time.
Robert Giardalas said on Sun, Oct 19, 2003 at 11:55:52PM -0400:
> I had some preliminary modifications of the parallel loading system
> proposed by James Hunt from IBM working for Debian, but it looked like
> it would speed things up less than 10%, which wasn't enough to lure me
> away from SysV
f you want 'em. I don't subscribe to this list, though, so
email me directly.
Z
> hello
>
> there has been a lot of interest lately on tecniques to obtain a
faster boot; for example
>
http://www-106.ibm.com/developerworks/linux/library/l-boot.html
http://www.fefe.de/mi
On Fri, Oct 17, 2003 at 11:53:18AM +0200, Erich Schubert wrote:
> minit is already really small. All it does is running processes and
> restarting them when they die. There seems to be little difference
> between what i can do with minit and with multiple runsv.
> And yes, i do know about shared me
Hi,
Please CC: me on replies, i'm not subscribed to debian-devel.
-rwxr-xr-x1 root root 5588 2003-09-15 17:41 /sbin/minit
-r-x--1 root root 5588 2003-09-24 10:31 /sbin/runit-init
-r-x--1 root root 8628 2003-09-24 10:31 /sbin/runit
-rwxr-xr-x1 root root
On Wed, Oct 15, 2003 at 11:12:26AM +0200, Erich Schubert wrote:
> If we want to introduce a new init system into debian, we should prepare
> a generic init framework (like many distributions already have in place)
> that allows for
> - silent/verbose boot and output redirection
> - fancy display o
On Wed, Oct 15, 2003 at 11:12:26AM +0200, Erich Schubert wrote:
> runit is okay, and it has debian packages already. What i didn't like
> about runit is the "forest" of processes it creates. The output of
> pstree is really fancy. ;-) Minit seems to be able to do most of this
> without using that m
* Erich Schubert <[EMAIL PROTECTED]> [031015 11:31]:
> - disabling of services in a consistent way (some are disabled via
> /etc/defaults/package, some expect you to edit the init.d script,
> some suggest removing the links)
I think removing the link is the way to go.
> - hooks for other init
On Tue, Oct 14, 2003 at 10:28:09AM +0200, Gerrit Pape wrote:
[...]
>
> Regards, Gerrit.
init
minit
runit
Gerrit!
Sounds like a name conflict ;)
--
Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69
-
Hi,
i have working minit packages (not sure if i uploaded them to
ppl.d.o/~erich/boot/ yet) and i've been using them for weeks to init my
system.
There are a couple of open issues, that is why i didn't upload them.
for example current init-scripts are not aware of the monitoring
capabilities; when
> there has been a lot of interest lately on tecniques to obtain a faster
> boot
It depends of what is machine meant to do.
If it's just a X workstation with some services run just for testing
purposes you can start just after syslog and xfs-xtt and X server.
I managed to lower the st
On Mon, Oct 13, 2003 at 12:05:24PM +0200, Andrea Mennucc wrote:
> there has been a lot of interest lately on tecniques to obtain a faster
> boot; for example
[...]
> http://www.fefe.de/minit/
[...]
> is anyone trying to implement the above in Debian?
I've implemented the runit
In article <[EMAIL PROTECTED]>,
Joe Drew <[EMAIL PROTECTED]> wrote:
>On Mon, 2003-10-13 at 06:57, Henrique de Moraes Holschuh wrote:
>> However, if you read the paper in http://people.d.o/~hmh, and implement the
>> demultiplexer, we could probably modify one of the above methods to work
>> well, w
On Mon, 2003-10-13 at 06:57, Henrique de Moraes Holschuh wrote:
> However, if you read the paper in http://people.d.o/~hmh, and implement the
> demultiplexer, we could probably modify one of the above methods to work
> well, while we implement ours...
After hearing your talk about init systems at
On Mon, Oct 13, 2003 at 12:05:24PM +0200, Andrea Mennucc wrote:
> I would be delighted to have a faster boot: my boot times (excluding
> BIOS) are 60sec-90sec (using the ditributed kernel by Herbert XU), and
> this is very long (particularly for my Freevo-box)
>
> is anyone tryi
On Mon, 13 Oct 2003, Andrea Mennucc wrote:
> there has been a lot of interest lately on tecniques to obtain a faster
> boot; for example
>
> http://www-106.ibm.com/developerworks/linux/library/l-boot.html
> http://www.fefe.de/minit/
> http://www.ussg.iu.edu/hypermail/linux/
hello
there has been a lot of interest lately on tecniques to obtain a faster
boot; for example
http://www-106.ibm.com/developerworks/linux/library/l-boot.html
http://www.fefe.de/minit/
http://www.ussg.iu.edu/hypermail/linux/kernel/0204.0/0674.html
http://www.atnf.csiro.au/people/rgooch/linux
49 matches
Mail list logo
