Re: simple task to speed up booting

2014-12-22 Thread Rui Paulo
On Dec 21, 2014, at 21:05, Ian Lepore i...@freebsd.org wrote:
 So all in all it seems like different kinds of IO need different
 throttling, something like the attached (which also still has some stats
 output in it).  I can't decide if it's worth committing... it'll have a
 lot of value to someone with slow serial and netbooting, is that common?

I think it's common.  It really depends on whether you can live with it or not. 
 Most people either change the baud rate or live with it. 

I think the rate of printing is pretty excessive and this patch seems to fix 
that, so why not commit it?

--
Rui Paulo



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-22 Thread John Baldwin
On Monday, December 22, 2014 12:05:43 am Ian Lepore wrote:
 On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
  The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
  large part of our boot time on systems with slow-ish serial consoles.
  
  I think right now it takes a step for each 512 byte read, reducing that
  to once every 64kB or even 1MB would be an improvement with the kind of
  kernel sizes we have today.
  
 
 I investigated this a bit today.  I instrumented the loader on arm to
 count how many times twiddle() is called while loading a 5.5MB kernel.
 When loading over NFS it was called 5580 times.  When loading from an
 sdcard it was called 284 times.
 
 Poking around in the code, it looks like NFS calls twiddle() once per 1K
 block read, CD9660 once per 2K block, and UFS and ext2fs once per
 filesystem blocksize block.  All of them have some other scattered
 twiddle calls while navigating metadata that probably don't add up to
 much compared to the bulk reading.
 
 My amd64 kernel is twice as big even with lots of the generic devices
 removed; that's a lot of IO.  But one twiddle per filesystem block
 shouldn't be so bad... let's call it 600 twiddles, each one writes 2
 bytes to serial, so a total of ~1200mS at 9600bps.  The same kernel
 loaded over nfs would cost over 20 seconds in serial output.
 
 So all in all it seems like different kinds of IO need different
 throttling, something like the attached (which also still has some stats
 output in it).  I can't decide if it's worth committing... it'll have a
 lot of value to someone with slow serial and netbooting, is that common?

9600 consoles are still fairly common, so if this makes a noticable difference 
for NFS, by all means test it and get it in.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-22 Thread Poul-Henning Kamp

In message 1419224743.1018.108.ca...@freebsd.org, Ian Lepore writes:

On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
 The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
 large part of our boot time on systems with slow-ish serial consoles.
 
I investigated this a bit today.  I instrumented the loader on arm to
count how many times twiddle() is called while loading a 5.5MB kernel.
When loading over NFS it was called 5580 times.  When loading from an
sdcard it was called 284 times.

It would be plenty if it twiddled once per second, in fact it would
probably be much better if it *only* twiddled once per second, because
the at least people could count the steps and gain some idea where
in the process the problem is.

So all in all it seems like different kinds of IO need different
throttling, something like the attached (which also still has some stats
output in it).  I can't decide if it's worth committing... it'll have a
lot of value to someone with slow serial and netbooting, is that common?

How about a compile time global divisor so people can reduce it
even further ?

But even without that: Please commit

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-22 Thread Ian Lepore
On Mon, 2014-12-22 at 15:15 +, Poul-Henning Kamp wrote:
 
 In message 1419224743.1018.108.ca...@freebsd.org, Ian Lepore writes:
 
 On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
  The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
  large part of our boot time on systems with slow-ish serial consoles.
  
 I investigated this a bit today.  I instrumented the loader on arm to
 count how many times twiddle() is called while loading a 5.5MB kernel.
 When loading over NFS it was called 5580 times.  When loading from an
 sdcard it was called 284 times.
 
 It would be plenty if it twiddled once per second, in fact it would
 probably be much better if it *only* twiddled once per second, because
 the at least people could count the steps and gain some idea where
 in the process the problem is.
 

Unfortunately we can't count on the availability of a useful clock in a
libstand environment.

 So all in all it seems like different kinds of IO need different
 throttling, something like the attached (which also still has some stats
 output in it).  I can't decide if it's worth committing... it'll have a
 lot of value to someone with slow serial and netbooting, is that common?
 
 How about a compile time global divisor so people can reduce it
 even further ?
 

Rather than compile-time I made it a run-time setting by adding a
twiddle_divisor variable to loader(8).   r276079 and r276087.

-- Ian


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-22 Thread Poul-Henning Kamp

In message 1419292392.1018.132.ca...@freebsd.org, Ian Lepore writes:

Rather than compile-time I made it a run-time setting by adding a
twiddle_divisor variable to loader(8).   r276079 and r276087.

Works for me,

Thanks a lot!

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-21 Thread Ian Lepore
On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
 The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
 large part of our boot time on systems with slow-ish serial consoles.
 
 I think right now it takes a step for each 512 byte read, reducing that
 to once every 64kB or even 1MB would be an improvement with the kind of
 kernel sizes we have today.
 

I investigated this a bit today.  I instrumented the loader on arm to
count how many times twiddle() is called while loading a 5.5MB kernel.
When loading over NFS it was called 5580 times.  When loading from an
sdcard it was called 284 times.

Poking around in the code, it looks like NFS calls twiddle() once per 1K
block read, CD9660 once per 2K block, and UFS and ext2fs once per
filesystem blocksize block.  All of them have some other scattered
twiddle calls while navigating metadata that probably don't add up to
much compared to the bulk reading.

My amd64 kernel is twice as big even with lots of the generic devices
removed; that's a lot of IO.  But one twiddle per filesystem block
shouldn't be so bad... let's call it 600 twiddles, each one writes 2
bytes to serial, so a total of ~1200mS at 9600bps.  The same kernel
loaded over nfs would cost over 20 seconds in serial output.

So all in all it seems like different kinds of IO need different
throttling, something like the attached (which also still has some stats
output in it).  I can't decide if it's worth committing... it'll have a
lot of value to someone with slow serial and netbooting, is that common?

-- Ian

Index: lib/libstand/cd9660.c
===
--- lib/libstand/cd9660.c	(revision 275941)
+++ lib/libstand/cd9660.c	(working copy)
@@ -281,7 +281,7 @@ cd9660_open(const char *path, struct open_file *f)
 	buf = malloc(buf_size = ISO_DEFAULT_BLOCK_SIZE);
 	vd = buf;
 	for (bno = 16;; bno++) {
-		twiddle();
+		twiddle(1);
 		rc = f-f_dev-dv_strategy(f-f_devdata, F_READ, cdb2devb(bno),
 	   ISO_DEFAULT_BLOCK_SIZE, buf, read);
 		if (rc)
@@ -314,7 +314,7 @@ cd9660_open(const char *path, struct open_file *f)
 
 		while (off  dsize) {
 			if ((off % ISO_DEFAULT_BLOCK_SIZE) == 0) {
-twiddle();
+twiddle(1);
 rc = f-f_dev-dv_strategy
 	(f-f_devdata, F_READ,
 	 cdb2devb(bno + boff),
@@ -374,7 +374,7 @@ cd9660_open(const char *path, struct open_file *f)
 
 		/* Check for Rock Ridge since we didn't in the loop above. */
 		bno = isonum_733(rec.extent) + isonum_711(rec.ext_attr_length);
-		twiddle();
+		twiddle(1);
 		rc = f-f_dev-dv_strategy(f-f_devdata, F_READ, cdb2devb(bno),
 		ISO_DEFAULT_BLOCK_SIZE, buf, read);
 		if (rc)
@@ -431,7 +431,7 @@ buf_read_file(struct open_file *f, char **buf_p, s
 		if (fp-f_buf == (char *)0)
 			fp-f_buf = malloc(ISO_DEFAULT_BLOCK_SIZE);
 
-		twiddle();
+		twiddle(32);
 		rc = f-f_dev-dv_strategy(f-f_devdata, F_READ,
 		cdb2devb(blkno), ISO_DEFAULT_BLOCK_SIZE, fp-f_buf, read);
 		if (rc)
Index: lib/libstand/ext2fs.c
===
--- lib/libstand/ext2fs.c	(revision 275941)
+++ lib/libstand/ext2fs.c	(working copy)
@@ -353,7 +353,7 @@ ext2fs_open(const char *upath, struct open_file *f
 	/* allocate space and read super block */
 	fs = (struct ext2fs *)malloc(sizeof(*fs));
 	fp-f_fs = fs;
-	twiddle();
+	twiddle(1);
 	error = (f-f_dev-dv_strategy)(f-f_devdata, F_READ,
 	EXT2_SBLOCK, EXT2_SBSIZE, (char *)fs, buf_size);
 	if (error)
@@ -395,7 +395,7 @@ ext2fs_open(const char *upath, struct open_file *f
 	len = blkgrps * fs-fs_bsize;
 
 	fp-f_bg = malloc(len);
-	twiddle();
+	twiddle(1);
 	error = (f-f_dev-dv_strategy)(f-f_devdata, F_READ,
 	EXT2_SBLOCK + EXT2_SBSIZE / DEV_BSIZE, len,
 	(char *)fp-f_bg, buf_size);
@@ -507,7 +507,7 @@ ext2fs_open(const char *upath, struct open_file *f
 if (error)
 	goto out;
 
-twiddle();
+twiddle(1);
 error = (f-f_dev-dv_strategy)(f-f_devdata,
 F_READ, fsb_to_db(fs, disk_block),
 fs-fs_bsize, buf, buf_size);
@@ -568,7 +568,7 @@ read_inode(ino_t inumber, struct open_file *f)
 	 * Read inode and save it.
 	 */
 	buf = malloc(fs-fs_bsize);
-	twiddle();
+	twiddle(1);
 	error = (f-f_dev-dv_strategy)(f-f_devdata, F_READ,
 	ino_to_db(fs, fp-f_bg, inumber), fs-fs_bsize, buf, rsize);
 	if (error)
@@ -665,7 +665,7 @@ block_map(struct open_file *f, daddr_t file_block,
 			if (fp-f_blk[level] == (char *)0)
 fp-f_blk[level] =
 	malloc(fs-fs_bsize);
-			twiddle();
+			twiddle(1);
 			error = (f-f_dev-dv_strategy)(f-f_devdata, F_READ,
 			fsb_to_db(fp-f_fs, ind_block_num), fs-fs_bsize,
 			fp-f_blk[level], fp-f_blksize[level]);
@@ -723,7 +723,7 @@ buf_read_file(struct open_file *f, char **buf_p, s
 			bzero(fp-f_buf, block_size);
 			fp-f_buf_size = block_size;
 		} else {
-			twiddle();
+			twiddle(4);
 			error = (f-f_dev-dv_strategy)(f-f_devdata, F_READ,
 			fsb_to_db(fs, disk_block), block_size,
 			fp-f_buf, 

Re: simple task to speed up booting

2014-12-15 Thread Olivier Cochard-Labbé
On Sun, Dec 14, 2014 at 3:52 PM, Ian Lepore i...@freebsd.org wrote:

 I was testing at 115kbps, maybe at 9600 it would be significant.  I
 don't understand why anything these days is still defaulting to 9600.
 It's the 21st century, but we never got the George Jetson flying cars we
 were promised, and apparently we're never going to break loose from the
 standards set by accoustic-coupled modems.


Because 9600 is the maximum value supported by our boot0sio ?

From sys/boot/i386/boot0/Makefile :

# Comm settings for boot0sio.
# Bit(s) Description
# 7-5data rate (110,150,300,600,1200,2400,4800,9600 bps)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


simple task to speed up booting

2014-12-14 Thread Poul-Henning Kamp
The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
large part of our boot time on systems with slow-ish serial consoles.

I think right now it takes a step for each 512 byte read, reducing that
to once every 64kB or even 1MB would be an improvement with the kind of
kernel sizes we have today.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-14 Thread Mehmet Erol Sanliturk
On Sun, Dec 14, 2014 at 2:32 AM, Poul-Henning Kamp p...@phk.freebsd.dk
wrote:

 The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
 large part of our boot time on systems with slow-ish serial consoles.

 I think right now it takes a step for each 512 byte read, reducing that
 to once every 64kB or even 1MB would be an improvement with the kind of
 kernel sizes we have today.

 --
 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 p...@freebsd.org | TCP/IP since RFC 956
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.
 ___



My wish would be to see listing explicit steps because when a lock occurs
it would be possible to report last completed ( or started ) step .
Otherwise , actually seeing a swirling set of characters is itself not much
useful other than showing there is a progress without understanding what is
going on .


If I were able to change anything in FreeBSD , my first choice would be to
change these swirling characters to list explicit names of completed tasks
( or  starting tasks which operating system developers would know best
which one is more useful ) .


Thank you very much .


Mehmet Erol Sanliturk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-14 Thread Ian Lepore
On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
 The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
 large part of our boot time on systems with slow-ish serial consoles.
 
 I think right now it takes a step for each 512 byte read, reducing that
 to once every 64kB or even 1MB would be an improvement with the kind of
 kernel sizes we have today.
 

I experimented with that a while ago using the attached patch and was
disappointed with the results.  As I vaguely remember it, a divisor of 8
looked fine, but had no significant speedup.  With a divisor of 32 the
difference was measureable (only like 1.5 seconds or so faster), but it
gave the impression that something was wrong, and the overall perception
was that it was slower rather than faster, despite what a stopwatch
said.

I was testing at 115kbps, maybe at 9600 it would be significant.  I
don't understand why anything these days is still defaulting to 9600.
It's the 21st century, but we never got the George Jetson flying cars we
were promised, and apparently we're never going to break loose from the
standards set by accoustic-coupled modems.

-- Ian

Index: lib/libstand/twiddle.c
===
--- lib/libstand/twiddle.c	(revision 274850)
+++ lib/libstand/twiddle.c	(working copy)
@@ -46,7 +46,11 @@ void
 twiddle()
 {
 	static int pos;
+	static int divisor;
 
-	putchar(|/-\\[pos++  3]);
-	putchar('\b');
+	if (divisor-- == 0) {
+		divisor = 32;
+		putchar(|/-\\[pos++  3]);
+		putchar('\b');
+	}
 }
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: simple task to speed up booting

2014-12-14 Thread Mike Karels
  On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
  The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
  large part of our boot time on systems with slow-ish serial consoles.
  
  I think right now it takes a step for each 512 byte read, reducing that
  to once every 64kB or even 1MB would be an improvement with the kind of
  kernel sizes we have today.
  

 I experimented with that a while ago using the attached patch and was
 disappointed with the results.  As I vaguely remember it, a divisor of 8
 looked fine, but had no significant speedup.  With a divisor of 32 the
 difference was measureable (only like 1.5 seconds or so faster), but it
 gave the impression that something was wrong, and the overall perception
 was that it was slower rather than faster, despite what a stopwatch
 said.

 I was testing at 115kbps, maybe at 9600 it would be significant.  I
 don't understand why anything these days is still defaulting to 9600.
 It's the 21st century, but we never got the George Jetson flying cars we
 were promised, and apparently we're never going to break loose from the
 standards set by accoustic-coupled modems.

AFAIK, accoustic-coupled modems topped out at 300 baud; that's the fastest
one I've used, anyway.

Defaults are hard to change, though.

Mike
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-14 Thread Alfred Perlstein

On Dec 14, 2014, at 6:52 AM, Ian Lepore wrote:

 On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
 The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
 large part of our boot time on systems with slow-ish serial consoles.
 
 I think right now it takes a step for each 512 byte read, reducing that
 to once every 64kB or even 1MB would be an improvement with the kind of
 kernel sizes we have today.
 
 
 I experimented with that a while ago using the attached patch and was
 disappointed with the results.  As I vaguely remember it, a divisor of 8
 looked fine, but had no significant speedup.  With a divisor of 32 the
 difference was measureable (only like 1.5 seconds or so faster), but it
 gave the impression that something was wrong, and the overall perception
 was that it was slower rather than faster, despite what a stopwatch
 said.
 
 I was testing at 115kbps, maybe at 9600 it would be significant.  I
 don't understand why anything these days is still defaulting to 9600.
 It's the 21st century, but we never got the George Jetson flying cars we
 were promised, and apparently we're never going to break loose from the
 standards set by accoustic-coupled modems.
 
 -- Ian
 
 Index: lib/libstand/twiddle.c
 ===
 --- lib/libstand/twiddle.c(revision 274850)
 +++ lib/libstand/twiddle.c(working copy)
 @@ -46,7 +46,11 @@ void
 twiddle()
 {
   static int pos;
 + static int divisor;
 
 - putchar(|/-\\[pos++  3]);
 - putchar('\b');
 + if (divisor-- == 0) {
 + divisor = 32;
 + putchar(|/-\\[pos++  3]);
 + putchar('\b');
 + }
 }

Ian, can divisor be exposed so that it can be set based on the loader's 
output device?  

That was we can preserve it for video consoles, but other things such as serial 
at = 9600 could throttle it (or even shut it off… twiddle_divisor = 
TWIDDLE_SHUT_OFF).

-Alfred

-Alfred

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-14 Thread Slawa Olhovchenkov
On Sun, Dec 14, 2014 at 07:52:11AM -0700, Ian Lepore wrote:

 On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
  The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
  large part of our boot time on systems with slow-ish serial consoles.
  
  I think right now it takes a step for each 512 byte read, reducing that
  to once every 64kB or even 1MB would be an improvement with the kind of
  kernel sizes we have today.
  
 
 I experimented with that a while ago using the attached patch and was
 disappointed with the results.  As I vaguely remember it, a divisor of 8
 looked fine, but had no significant speedup.  With a divisor of 32 the
 difference was measureable (only like 1.5 seconds or so faster), but it
 gave the impression that something was wrong, and the overall perception
 was that it was slower rather than faster, despite what a stopwatch
 said.
 
 I was testing at 115kbps, maybe at 9600 it would be significant.  I
 don't understand why anything these days is still defaulting to 9600.
 It's the 21st century, but we never got the George Jetson flying cars we
 were promised, and apparently we're never going to break loose from the
 standards set by accoustic-coupled modems.

You not always working with self-owned servers.
Default is 9600,8n1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-14 Thread Poul-Henning Kamp

In message 1418568731.935.8.ca...@freebsd.org, Ian Lepore writes:

It's the 21st century, but we never got the George Jetson flying cars we
were promised, and apparently we're never going to break loose from the
standards set by accoustic-coupled modems.

9600 is not from accoustic-coupled modems, but from RS-232 runs on unshielded
telephone wire in office environments.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org