Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Apr 2016 19:43:04 -0400
From:      Allan Jude <allanjude@freebsd.org>
To:        Adrian Chadd <adrian.chadd@gmail.com>
Cc:        "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r298230 - in head: lib/libstand sys/boot/common sys/boot/efi/libefi sys/boot/efi/loader sys/boot/i386/libfirewire sys/boot/i386/libi386 sys/boot/i386/loader sys/boot/mips/beri/loader sy...
Message-ID:  <57157108.6090500@freebsd.org>
In-Reply-To: <CAJ-Vmo=WX8xwnuvbPJMib3BMuVKjQMkKt1qXkx=TPH5wZYPM1A@mail.gmail.com>
References:  <201604182309.u3IN9MC6047480@repo.freebsd.org> <CAJ-Vmo=WX8xwnuvbPJMib3BMuVKjQMkKt1qXkx=TPH5wZYPM1A@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-04-18 19:36, Adrian Chadd wrote:
> Someone pointed out how this bloats out memory requirement in loader.
>
> Did anyone check that?
>
> -adrian
>

I tested down to 128mb of ram in QEMU, booted from the installer ISO, 
did the install, and booted the installed system without issue.


>
> On 18 April 2016 at 16:09, Allan Jude <allanjude@freebsd.org> wrote:
>> Author: allanjude
>> Date: Mon Apr 18 23:09:22 2016
>> New Revision: 298230
>> URL: https://svnweb.freebsd.org/changeset/base/298230
>>
>> Log:
>>    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
>>


-- 
Allan Jude



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57157108.6090500>