Date: Mon, 01 Oct 2012 19:22:39 +0400 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r241053 - in head/sys/boot: common i386/libi386 uboot/lib userboot/userboot Message-ID: <5069B53F.5040004@yandex.ru> In-Reply-To: <201210010753.59816.jhb@freebsd.org> References: <201209291647.q8TGlvbr058837@svn.freebsd.org> <201210010753.59816.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01.10.2012 15:53, John Baldwin wrote: >> Introduce new cache layer to resolve this problem. It is independent >> and doesn't need initialization like bcache, and will work by default >> for all loaders which use the new DISK API. A successful disk_open() >> call to each new disk or partition produces new entry in the cache. >> Even more, when disk was already open, now opening of any nested >> partitions does not require reading top level partition table. >> So, if without this cache, partition table metadata was read around >> 20-50 times during boot, now it reads only once. This affects the booting >> from GPT and MBR from the UFS. > > ...and removes support for removable media like floppies. That may be the > proper thing to do at this stage (though I think that affects PC98 still > perhaps?) However, removing suppot for removable media should be an > intentional decision, not a side effect. The bcache was simplistic > precisely to support floppies. Hi, John, I think it shouldn't affect floppies support. I'm unable to test this, and I don't remember exactly, but floppies don't have partition tables, or just have simple MBR. So, when access to the floppy will be performed first time, the following cache entry will be created "disk0: -> some_offset", probably an offset will be zero. And when you change the floppy this offset still remain the same. There is a lot of other places in the libstand, where similar behavior still remain (i mean, one operation initiates several unneeded reads): * Each open() call initiates read file system metadata. * We have the support of different file systems. Some of those are real file systems, other aren't - gzip, bzip, split. During boot loader tries to open several files, which don't exists by default. Each this attempt initiates reading of metadata of each file system several times. Why? When we do first read we can determine that we have UFS on this media, why do we trying search msdos or ext2fs here? Ok, when we fail to open this file on the all of file systems, we are going to try them again with ".gz" extension... Make a new loader is very hard task, but we can optimize this and don't do these unneeded operations. I have added rdtsc() call at the beginning of the main() and before the kernel start, and I did several tests with today's loader and with old one (before all my changes). So, the results are: UFS+GPT ZFS+GPT ZFS+GPT+several disks new_loader 7,203s 20,584s 26,079s old_loader 4,334s 9,422s 11,245s -- WBR, Andrey V. Elsukov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5069B53F.5040004>