From owner-freebsd-current Mon Dec 27 17: 2: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id ADEA914E86 for ; Mon, 27 Dec 1999 17:01:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA34874; Mon, 27 Dec 1999 17:01:55 -0800 (PST) (envelope-from dillon) Date: Mon, 27 Dec 1999 17:01:55 -0800 (PST) From: Matthew Dillon Message-Id: <199912280101.RAA34874@apollo.backplane.com> To: Poul-Henning Kamp Cc: freebsd-current@FreeBSD.ORG Subject: Re: Proposed patch to fix VN device (again) References: <8502.946341855@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In message <199912280026.QAA34572@apollo.backplane.com>, Matthew Dillon writes: : :> VN calls vm_pager_strategy() which collects I/O in filesystem buffers :> (bp)'s in order to cluster the I/O, and you cannot initiate I/O on :> filesystem buffers without a valid b_dev. :> :> So, the jist of the problem is that in order to get reasonable performance :> out of the thing (i.e. not issue 4K I/O's to the disk), we have to use :> filesystem buffers which means the bp must be properly initialized. : :vm_pager_strategy() branches out based on the object type and ends up :in swap_pager_strategy() which only uses b_dev after calling swstrategy() :then only in a diagnostic printf which we had better never reach. : :swstrategy() which initializes bp->b_dev to the right physical device. : :I'm afraid I don't see why or where we would need the bogus /dev/drum dev_t. : :Furthermore, since we have already clustered above the VN device, :I seriously doubt the utility of doing it again between VN and the :swapdevice. : :-- :Poul-Henning Kamp FreeBSD coreteam member :phk@FreeBSD.ORG "Real hackers run -current on their laptop." :FreeBSD -- It will take a long time before progress goes too far! Umm. Poul, I know you don't like the idea but you obviously do not understand the code in question. First, you are confusing the underlying swap devices that we swapon on with the parent swap device that controls them. The parent swap device needs to have a dev_t - it does not currently have one, and this is the entry point that the buffers are going into. The underlying swap devices *already* have a dev_t. My kernel crashes on a NULL bp->b_dev. In fact, it also crashes on a NULL vp->v_rdev. Without the patch. So if you are trying to say that b_dev is being magically set I gotta tell you that my kernel dumps say otherwise. Second, the clustering done above the VN device is done by the filesystem and has no understanding of whether the underlying media controlled by the VN device can itself be clustered in the same way. When using swap as backing store what may appear to be clusterable by the filesystem may actually *NOT* be clusterable when you get into the swap device due to potentially non-contiguous mappings as well as border-crossings between interleaved swap devices. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message