Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Nov 2015 11:55:55 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 204716] boot loader bcache is trashed by larger sequential reads from zfs/ufs
Message-ID:  <bug-204716-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204716

            Bug ID: 204716
           Summary: boot loader bcache is trashed by larger sequential
                    reads from zfs/ufs
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: tsoome@me.com

Created attachment 163375
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163375&action=edit
loader-performance-boost patch

this work is direct result of findings while working on loader support on
illumos; since illumos kernel needs not just kernel itself but also rather
large boot_archive (especially in case of installer image or smartos), I have
noticed slow read of large files.

while investigating possible causes, I noticed the block cache trashing (huge
number of misses from bcachestat) after loading large files. So i did implement
additional mechanism to make larger reads to bypass the bcache and it resulted
huge boost in file loading, also quite visible in case of freebsd.

note the switch off condition for bcache in libstand/read.c is arbitrary
(2*512B sectors) and perhaps the better solution is possible, however it seems
to provide "good enough" results.  read() change is to help to boost zfs
reader, for ufs I did add bcache disabler for file read call, so other reads
should benefit from bcache.

Since for illumos support I had to add mechanism to recognize gzip'ped files, I
did leave in the compression specific flags in attached diff, perhaps the order
of the flags should be reversed to avoid including compression flags for
fbsd... for now I left it as is:)

-- 
You are receiving this mail because:
You are the assignee for the bug.



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