svn commit: r241053 - in head/sys/boot: common i386/libi386 uboot/lib userboot/userboot

[Andrey V. Elsukov]

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