From owner-svn-src-head@FreeBSD.ORG Mon Oct 1 15:22:44 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52677106564A; Mon, 1 Oct 2012 15:22:44 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [IPv6:2a02:6b8:0:f05::2]) by mx1.freebsd.org (Postfix) with ESMTP id A727C8FC08; Mon, 1 Oct 2012 15:22:43 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward2h.mail.yandex.net (Yandex) with ESMTP id 0FE797009FA; Mon, 1 Oct 2012 19:22:41 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 94B611700058; Mon, 1 Oct 2012 19:22:41 +0400 (MSK) Received: from dynamic-178-141-5-77.kirov.comstar-r.ru (dynamic-178-141-5-77.kirov.comstar-r.ru [178.141.5.77]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id MeomAQX8-MfoWF5IQ; Mon, 1 Oct 2012 19:22:41 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1349104961; bh=FL2i8shoYO4qJgS3tqRV6g7iAhkccuifw33QZQLW1pU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=j4YzVZ//w+qxX0SOW7cxA/BdX20vjNYP9UtJap5LXue56pTHbkTr9ymS9/NFve6tN KkFcodImyF7lJnLNsk+mOX8x7/r8/qiHf2nfWI9q9a4rLFYHiRpVc7hHNZK974KjSX HmhY46Bqz6XNVwaIJ8j2PYSx2+DSSALL0OMfiwOQ= Message-ID: <5069B53F.5040004@yandex.ru> Date: Mon, 01 Oct 2012 19:22:39 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: John Baldwin References: <201209291647.q8TGlvbr058837@svn.freebsd.org> <201210010753.59816.jhb@freebsd.org> In-Reply-To: <201210010753.59816.jhb@freebsd.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Oct 2012 15:29:24 +0000 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 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:22:44 -0000 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