src/sys/boot/alpha/libalpha, branch release/3.5.0_cvs FreeBSD source tree This commit was manufactured by cvs2svn to create tag 2000-06-25T00:20:49+00:00 cvs2svn cvs2svn@FreeBSD.org 2000-06-25T00:20:49+00:00 8e878a0310eae754021dbd73ca928eaf7cf6a65c 'RELENG_3_5_0_RELEASE'. This commit was manufactured to restore the state of the 3.5-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs. 
'RELENG_3_5_0_RELEASE'.

This commit was manufactured to restore the state of the 3.5-RELEASE image.
Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.
MFC the bcache loader fixes. 2000-03-16T18:22:51+00:00 John Baldwin jhb@FreeBSD.org 2000-03-16T18:22:51+00:00 51edb118ef932bb21a27a4377855b29993153803 Submitted by: dcs 
Submitted by:	dcs
$Id$ -> $FreeBSD$ 1999-08-29T16:33:42+00:00 Peter Wemm peter@FreeBSD.org 1999-08-29T16:33:42+00:00 c4f617ca01b475bdf034553dfe123deeb1589899 






MFC 1.6 -> 1.7: Handle flags from the "boot" command.
1999-08-21T01:49:41+00:00

John Polstra
jdp@FreeBSD.org

1999-08-21T01:49:41+00:00

4323e3278c9f94750b0b3bc81e0cf41111c24093












Include "bootstrap.h" to get a definition for bcache_devdata.
1998-11-03T23:44:49+00:00

Mike Smith
msmith@FreeBSD.org

1998-11-03T23:44:49+00:00

631746a1719f3ac2ea027fd93de614e73726aa67

Submitted by:	jkh





Submitted by:	jkh







Implement a simple LRU block cache.  By default this is initialised to 16k,
1998-11-02T23:28:11+00:00

Mike Smith
msmith@FreeBSD.org

1998-11-02T23:28:11+00:00

af1f6e0673515936750cc5079ca5afd238ec925c

and will bypass transfers for more than 8k.  Blocks are invalidated after
2 seconds, so removable media should not confuse the cache.

The 8k threshold is a compromise; all UFS transfers performed by
libstand are 8k or less, so large file reads thrash the cache.
However many filesystem metadata operations are also performed using
8k blocks, so using a lower threshold gives poor performance.

Those of you with an eye for cache algorithms are welcome to tell me
how badly this one sucks; you can start with the 'bcachestats' command
which will print the contents of the cache and access statistics.





and will bypass transfers for more than 8k.  Blocks are invalidated after
2 seconds, so removable media should not confuse the cache.

The 8k threshold is a compromise; all UFS transfers performed by
libstand are 8k or less, so large file reads thrash the cache.
However many filesystem metadata operations are also performed using
8k blocks, so using a lower threshold gives poor performance.

Those of you with an eye for cache algorithms are welcome to tell me
how badly this one sucks; you can start with the 'bcachestats' command
which will print the contents of the cache and access statistics.







* Extend the memory available for the heap from 256k to 512k.
1998-10-31T17:12:32+00:00

Doug Rabson
dfr@FreeBSD.org

1998-10-31T17:12:32+00:00

06feb69276c45157af7e9e5bbbf56d74cd77ebfe

* Embed the stack into the bss section for loader and netboot.  This
  is required for netboot since otherwise the stack would be inside our
  heap.
* Install loader and netboot in /boot by default.
* Fix getbootfile so that it searches for a ',' instead of a ';'
  when terminating the filename.





* Embed the stack into the bss section for loader and netboot.  This
  is required for netboot since otherwise the stack would be inside our
  heap.
* Install loader and netboot in /boot by default.
* Fix getbootfile so that it searches for a ',' instead of a ';'
  when terminating the filename.







Turn of disk debugging by default (suppress annoying "partition marked as
1998-10-16T19:26:11+00:00

Mike Smith
msmith@FreeBSD.org

1998-10-16T19:26:11+00:00

d800cebf6173364d6a478d8ae36a94f9096b0aae

unused" diagnostic on floppies).





unused" diagnostic on floppies).







Fix the bootinfo so that the right values actual make it into the kernel.
1998-10-15T21:55:58+00:00

Doug Rabson
dfr@FreeBSD.org

1998-10-15T21:55:58+00:00

6214a95af0bd5d727210da4ccbd5f4d6b55b7d79












Get the last used address via a more conservative method, don't depend
1998-10-15T17:06:36+00:00

Peter Wemm
peter@FreeBSD.org

1998-10-15T17:06:36+00:00

f03d6f87b33ef0c751f5645013823cf0a6cbad03

on the module chain being in increasing address order.





on the module chain being in increasing address order.