d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fff006f7c0
freebsd-skq/sys/boot/common/bcache.c

457 lines
12 KiB
C
Raw Normal View History

Add BootForth hooks; if BOOT_FORTH is defined, pass every line read to the Forth interpreter. Instantiate all of our inbuilt commands as Forth words, and handle them being called from there. Add my copyright to the bcache module (oops).
1998-11-04 00:29:01 +00:00
/*-
* Copyright (c) 1998 Michael Smith <msmith@freebsd.org>
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
* Copyright 2015 Toomas Soome <tsoome@me.com>
Add BootForth hooks; if BOOT_FORTH is defined, pass every line read to the Forth interpreter. Instantiate all of our inbuilt commands as Forth words, and handle them being called from there. Add my copyright to the bcache module (oops).
1998-11-04 00:29:01 +00:00
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
*/
Use __FBSDID(). Also some minor style cleanups.
2003-08-25 23:30:41 +00:00
#include <sys/cdefs.h>
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
#include <sys/param.h>
Use __FBSDID(). Also some minor style cleanups.
2003-08-25 23:30:41 +00:00
__FBSDID("$FreeBSD$");
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
/*
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
* Simple hashed block cache
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
*/
Use the correct printf specifier. PR: 47187
2004-10-03 16:34:01 +00:00
#include <sys/stdint.h>
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
#include <stand.h>
#include <string.h>
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
#include <strings.h>
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
#include "bootstrap.h"
/* #define BCACHE_DEBUG */
#ifdef BCACHE_DEBUG
Update to C99, s/__FUNCTION__/__func__/, also don't use ANSI string concatenation.
2001-12-10 08:09:49 +00:00
# define DEBUG(fmt, args...) printf("%s: " fmt "\n" , __func__ , ## args)
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
#else
# define DEBUG(fmt, args...)
#endif
struct bcachectl
{
daddr_t bc_blkno;
Ok, the entry aging algorithm sucked; 1s time resolution is not enough for LRU. Use a 31-bit counter instead. If we decide to do heavy I/O through the bootloader this will have to be revisited.
1998-11-02 23:50:59 +00:00
int bc_count;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
};
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
/*
* bcache per device node. cache is allocated on device first open and freed
* on last close, to save memory. The issue there is the size; biosdisk
* supports up to 31 (0x1f) devices. Classic setup would use single disk
* to boot from, but this has changed with zfs.
*/
struct bcache {
struct bcachectl *bcache_ctl;
caddr_t bcache_data;
u_int bcache_nblks;
size_t ra;
};
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
static u_int bcache_total_nblks; /* set by bcache_init */
static u_int bcache_blksize; /* set by bcache_init */
static u_int bcache_numdev; /* set by bcache_add_dev */
/* statistics */
static u_int bcache_units; /* number of devices with cache */
static u_int bcache_unit_nblks; /* nblocks per unit */
static u_int bcache_hits;
static u_int bcache_misses;
static u_int bcache_ops;
static u_int bcache_bypasses;
static u_int bcache_bcount;
static u_int bcache_rablks;
#define BHASH(bc, blkno) ((blkno) & ((bc)->bcache_nblks - 1))
#define BCACHE_LOOKUP(bc, blkno) \
((bc)->bcache_ctl[BHASH((bc), (blkno))].bc_blkno != (blkno))
#define BCACHE_READAHEAD 256
#define BCACHE_MINREADAHEAD 32
static void bcache_invalidate(struct bcache *bc, daddr_t blkno);
static void bcache_insert(struct bcache *bc, daddr_t blkno);
static void bcache_free_instance(struct bcache *bc);
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
/*
* Initialise the cache for (nblks) of (bsize).
*/
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
void
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
bcache_init(u_int nblks, size_t bsize)
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
{
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
/* set up control data */
bcache_total_nblks = nblks;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
bcache_blksize = bsize;
bcache_strategy() now receives an unit number, and keep track of what was the last unit number received. If it changes, it flushes the cache. Add bcache_flash(). The actual fix is sligthly different from the one in the PR. PR: 17098 Submitted by: John Hood <jhood@sitaranetworks.com>
2000-03-15 01:56:12 +00:00
}
/*
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
* add number of devices to bcache. we have to divide cache space
* between the devices, so bcache_add_dev() can be used to set up the
* number. The issue is, we need to get the number before actual allocations.
* bcache_add_dev() is supposed to be called from device init() call, so the
* assumption is, devsw dv_init is called for plain devices first, and
* for zfs, last.
bcache_strategy() now receives an unit number, and keep track of what was the last unit number received. If it changes, it flushes the cache. Add bcache_flash(). The actual fix is sligthly different from the one in the PR. PR: 17098 Submitted by: John Hood <jhood@sitaranetworks.com>
2000-03-15 01:56:12 +00:00
*/
void
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
bcache_add_dev(int devices)
bcache_strategy() now receives an unit number, and keep track of what was the last unit number received. If it changes, it flushes the cache. Add bcache_flash(). The actual fix is sligthly different from the one in the PR. PR: 17098 Submitted by: John Hood <jhood@sitaranetworks.com>
2000-03-15 01:56:12 +00:00
{
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
bcache_numdev += devices;
}
void *
bcache_allocate(void)
{
u_int i;
struct bcache *bc = malloc(sizeof (struct bcache));
int disks = bcache_numdev;
if (disks == 0)
disks = 1; /* safe guard */
if (bc == NULL) {
errno = ENOMEM;
return (bc);
}
/*
* the bcache block count must be power of 2 for hash function
*/
i = fls(disks) - 1; /* highbit - 1 */
if (disks > (1 << i)) /* next power of 2 */
i++;
bc->bcache_nblks = bcache_total_nblks >> i;
bcache_unit_nblks = bc->bcache_nblks;
bc->bcache_data = malloc(bc->bcache_nblks * bcache_blksize);
if (bc->bcache_data == NULL) {
/* dont error out yet. fall back to 32 blocks and try again */
bc->bcache_nblks = 32;
bc->bcache_data = malloc(bc->bcache_nblks * bcache_blksize);
}
bc->bcache_ctl = malloc(bc->bcache_nblks * sizeof(struct bcachectl));
bcache_strategy() now receives an unit number, and keep track of what was the last unit number received. If it changes, it flushes the cache. Add bcache_flash(). The actual fix is sligthly different from the one in the PR. PR: 17098 Submitted by: John Hood <jhood@sitaranetworks.com>
2000-03-15 01:56:12 +00:00
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
if ((bc->bcache_data == NULL) || (bc->bcache_ctl == NULL)) {
bcache_free_instance(bc);
errno = ENOMEM;
return(NULL);
}
bcache_strategy() now receives an unit number, and keep track of what was the last unit number received. If it changes, it flushes the cache. Add bcache_flash(). The actual fix is sligthly different from the one in the PR. PR: 17098 Submitted by: John Hood <jhood@sitaranetworks.com>
2000-03-15 01:56:12 +00:00
/* Flush the cache */
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
for (i = 0; i < bc->bcache_nblks; i++) {
bc->bcache_ctl[i].bc_count = -1;
bc->bcache_ctl[i].bc_blkno = -1;
This fixes a bug in the bcache code whereby false cache hits occur the first time block 0 is read. This fix initialises the block numbers to -1 which isn't the most correct thing for a daddr_t but it isn't likely to cause a problem in the boot blocks and it could do with a more thought out fix later. The bug is probably benign on the i386 but on the alpha it can cause initial file opens to fail. This is the cause of the "can't open /boot/boot.conf" errors. It appears on the alpha because of a number of combining factors. On the alpha the LABELSECTOR is 0 so block 0 needs to be read in from the media. The first time this happens you get a false hit because the bc_blkno field is zero initially. Also, the timestamp check against this cache hit succeeds because on the alpha a hacked getsecs() function can return 0 when it starts counting so that the zero initial timestamp + BCACHE_TIMEOUT is greater than the current time until getsecs() has counted passed BCACHE_TIMEOUT. The overall effect is that the first open() that occurs gets a false cache hit and returns garbage to the bd_strategy() function which then fails the open() call. This false hit then stays in the cache until BCACHE_TIMEOUT getsecs() ticks have passed; all open() calls during this time fail. This explains why you can generally access the media by the time you get to interp() and start issuing commands but the earlier attempts to run the boot scripts are failing. It's possible that this is causing the problem switching to the mfsroot floppy as well but I haven't confirmed that.
1998-11-19 18:12:03 +00:00
}
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
bcache_units++;
bc->ra = BCACHE_READAHEAD; /* optimistic read ahead */
return (bc);
}
void
bcache_free(void *cache)
{
struct bcache *bc = cache;
if (bc == NULL)
return;
bcache_free_instance(bc);
bcache_units--;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
}
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
/*
* Handle a write request; write directly to the disk, and populate the
* cache with the new values.
*/
static int
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
write_strategy(void *devdata, int rw, daddr_t blk, size_t size,
char *buf, size_t *rsize)
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
{
struct bcache_devdata *dd = (struct bcache_devdata *)devdata;
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
struct bcache *bc = dd->dv_cache;
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
daddr_t i, nblk;
nblk = size / bcache_blksize;
/* Invalidate the blocks being written */
for (i = 0; i < nblk; i++) {
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
bcache_invalidate(bc, blk + i);
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
}
/* Write the blocks */
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
return (dd->dv_strategy(dd->dv_devdata, rw, blk, size, buf, rsize));
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
}
/*
* Handle a read request; fill in parts of the request that can
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
* be satisfied by the cache, use the supplied strategy routine to do
* device I/O and then use the I/O results to populate the cache.
*/
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
static int
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
read_strategy(void *devdata, int rw, daddr_t blk, size_t size,
char *buf, size_t *rsize)
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
{
struct bcache_devdata *dd = (struct bcache_devdata *)devdata;
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
struct bcache *bc = dd->dv_cache;
size_t i, nblk, p_size, r_size, complete, ra;
int result;
daddr_t p_blk;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
caddr_t p_buf;
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
if (bc == NULL) {
errno = ENODEV;
return (-1);
}
if (rsize != NULL)
*rsize = 0;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
nblk = size / bcache_blksize;
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
if (nblk == 0 && size != 0)
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
nblk++;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
result = 0;
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
complete = 1;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
/* Satisfy any cache hits up front, break on first miss */
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
for (i = 0; i < nblk; i++) {
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
if (BCACHE_LOOKUP(bc, (daddr_t)(blk + i))) {
bcache_misses += (nblk - i);
complete = 0;
if (nblk - i > BCACHE_MINREADAHEAD && bc->ra > BCACHE_MINREADAHEAD)
bc->ra >>= 1; /* reduce read ahead */
break;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
} else {
bcache_hits++;
}
}
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
if (complete) { /* whole set was in cache, return it */
if (bc->ra < BCACHE_READAHEAD)
bc->ra <<= 1; /* increase read ahead */
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
bcopy(bc->bcache_data + (bcache_blksize * BHASH(bc, blk)), buf, size);
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
goto done;
}
/*
* Fill in any misses. From check we have i pointing to first missing
* block, read in all remaining blocks + readahead.
* We have space at least for nblk - i before bcache wraps.
*/
p_blk = blk + i;
p_buf = bc->bcache_data + (bcache_blksize * BHASH(bc, p_blk));
r_size = bc->bcache_nblks - BHASH(bc, p_blk); /* remaining blocks */
p_size = MIN(r_size, nblk - i); /* read at least those blocks */
ra = bc->bcache_nblks - BHASH(bc, p_blk + p_size);
if (ra != bc->bcache_nblks) { /* do we have RA space? */
ra = MIN(bc->ra, ra);
p_size += ra;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
}
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
/* invalidate bcache */
for (i = 0; i < p_size; i++) {
bcache_invalidate(bc, p_blk + i);
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
}
bcache read ahead may attempt to read past end of disk The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache. This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: jhb, np Differential Revision: https://reviews.freebsd.org/D6109
2016-05-01 21:06:59 +00:00
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
r_size = 0;
bcache read ahead may attempt to read past end of disk The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache. This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: jhb, np Differential Revision: https://reviews.freebsd.org/D6109
2016-05-01 21:06:59 +00:00
/*
* with read-ahead, it may happen we are attempting to read past
* disk end, as bcache has no information about disk size.
* in such case we should get partial read if some blocks can be
* read or error, if no blocks can be read.
* in either case we should return the data in bcache and only
* return error if there is no data.
*/
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
result = dd->dv_strategy(dd->dv_devdata, rw, p_blk,
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
p_size * bcache_blksize, p_buf, &r_size);
r_size /= bcache_blksize;
for (i = 0; i < r_size; i++)
bcache_insert(bc, p_blk + i);
bcache read ahead may attempt to read past end of disk The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache. This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: jhb, np Differential Revision: https://reviews.freebsd.org/D6109
2016-05-01 21:06:59 +00:00
/* update ra statistics */
if (r_size != 0) {
if (r_size < p_size)
bcache_rablks += (p_size - r_size);
else
bcache_rablks += ra;
}
/* check how much data can we copy */
for (i = 0; i < nblk; i++) {
if (BCACHE_LOOKUP(bc, (daddr_t)(blk + i)))
break;
}
bcache should support reads shorter than sector size dosfs (fat file systems) can perform reads of partial sectors bcache should support such reads. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D6475
2016-07-30 17:45:56 +00:00
if (size > i * bcache_blksize)
size = i * bcache_blksize;
bcache read ahead may attempt to read past end of disk The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache. This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: jhb, np Differential Revision: https://reviews.freebsd.org/D6109
2016-05-01 21:06:59 +00:00
if (size != 0) {
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
bcopy(bc->bcache_data + (bcache_blksize * BHASH(bc, blk)), buf, size);
bcache read ahead may attempt to read past end of disk The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache. This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: jhb, np Differential Revision: https://reviews.freebsd.org/D6109
2016-05-01 21:06:59 +00:00
result = 0;
}
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
done:
if ((result == 0) && (rsize != NULL))
*rsize = size;
return(result);
}
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
/*
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
* Requests larger than 1/2 cache size will be bypassed and go
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
* directly to the disk. XXX tune this.
*/
int
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
bcache_strategy(void *devdata, int rw, daddr_t blk, size_t size,
char *buf, size_t *rsize)
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
{
struct bcache_devdata *dd = (struct bcache_devdata *)devdata;
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
struct bcache *bc = dd->dv_cache;
u_int bcache_nblks = 0;
int nblk, cblk, ret;
size_t csize, isize, total;
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
bcache_ops++;
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
if (bc != NULL)
bcache_nblks = bc->bcache_nblks;
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
/* bypass large requests, or when the cache is inactive */
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
if (bc == NULL ||
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
((size * 2 / bcache_blksize) > bcache_nblks)) {
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
DEBUG("bypass %d from %d", size / bcache_blksize, blk);
bcache_bypasses++;
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
return (dd->dv_strategy(dd->dv_devdata, rw, blk, size, buf, rsize));
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
}
switch (rw) {
case F_READ:
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
nblk = size / bcache_blksize;
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
if (size != 0 && nblk == 0)
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
nblk++; /* read at least one block */
ret = 0;
total = 0;
while(size) {
cblk = bcache_nblks - BHASH(bc, blk); /* # of blocks left */
cblk = MIN(cblk, nblk);
if (size <= bcache_blksize)
csize = size;
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
else
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
csize = cblk * bcache_blksize;
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
ret = read_strategy(devdata, rw, blk, csize, buf+total, &isize);
bcache read ahead may attempt to read past end of disk The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache. This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: jhb, np Differential Revision: https://reviews.freebsd.org/D6109
2016-05-01 21:06:59 +00:00
/*
* we may have error from read ahead, if we have read some data
* return partial read.
*/
if (ret != 0 || isize == 0) {
if (total != 0)
ret = 0;
break;
}
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
blk += isize / bcache_blksize;
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
total += isize;
size -= isize;
nblk = size / bcache_blksize;
}
if (rsize)
*rsize = total;
return (ret);
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
case F_WRITE:
dosfs support in libstand is broken since r298230 Apparently the libstand dosfs optimization is a bit too optimistic and did introduce possible memory corruption. This patch is backing out the bad part and since this results in dosfs reading full blocks now, we can also remove extra offset argument from dv_strategy callback. The analysis of the issue and the backout patch is provided by Mikhail Kupchik. PR: 214423 Submitted by: Mikhail Kupchik Reported by: Mikhail Kupchik Reviewed by: bapt, allanjude Approved by: allanjude (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8644
2016-12-30 19:06:29 +00:00
return write_strategy(devdata, rw, blk, size, buf, rsize);
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
}
return -1;
}
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
/*
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
* Free allocated bcache instance
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
*/
static void
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
bcache_free_instance(struct bcache *bc)
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
{
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
if (bc != NULL) {
if (bc->bcache_ctl)
free(bc->bcache_ctl);
if (bc->bcache_data)
free(bc->bcache_data);
free(bc);
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
}
}
/*
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
* Insert a block into the cache.
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
*/
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
static void
bcache_insert(struct bcache *bc, daddr_t blkno)
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
{
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
u_int cand;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
cand = BHASH(bc, blkno);
DEBUG("insert blk %llu -> %u # %d", blkno, cand, bcache_bcount);
bc->bcache_ctl[cand].bc_blkno = blkno;
bc->bcache_ctl[cand].bc_count = bcache_bcount++;
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
}
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
/*
* Invalidate a block from the cache.
*/
static void
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
bcache_invalidate(struct bcache *bc, daddr_t blkno)
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
{
u_int i;
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
i = BHASH(bc, blkno);
if (bc->bcache_ctl[i].bc_blkno == blkno) {
bc->bcache_ctl[i].bc_count = -1;
bc->bcache_ctl[i].bc_blkno = -1;
DEBUG("invalidate blk %llu", blkno);
Add support for writing blocks to the loader's disk cache. PR: kern/32389 Submitted by: Jonathan Mini <mini@haikugeek.com> Sponsored by: ClickArray, Inc.
2001-12-11 00:10:00 +00:00
}
}
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
#ifndef BOOT2
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
COMMAND_SET(bcachestat, "bcachestat", "get disk block cache stats", command_bcache);
static int
command_bcache(int argc, char *argv[])
{
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
if (argc != 1) {
command_errmsg = "wrong number of arguments";
return(CMD_ERROR);
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
}
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
printf("\ncache blocks: %d\n", bcache_total_nblks);
printf("cache blocksz: %d\n", bcache_blksize);
printf("cache readahead: %d\n", bcache_rablks);
printf("unit cache blocks: %d\n", bcache_unit_nblks);
printf("cached units: %d\n", bcache_units);
printf("%d ops %d bypasses %d hits %d misses\n", bcache_ops,
bcache_bypasses, bcache_hits, bcache_misses);
Implement a simple LRU block cache. By default this is initialised to 16k, 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.
1998-11-02 23:28:11 +00:00
return(CMD_OK);
}
A new implementation of the loader block cache The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy. Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks. Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device. The cache also implements limited read-ahead to increase performance. To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache. Booting from a virtual CD over IPMI: 0ms latency, before: 27 second, after: 7 seconds 60ms latency, before: over 12 minutes, after: under 5 minutes. Submitted by: Toomas Soome <tsoome@me.com> Reviewed by: delphij (previous version), emaste (previous version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
#endif
Reference in New Issue Copy Permalink