Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 05 Feb 2001 22:17:15 +0100
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        mjacob@feral.com
Cc:        arch@FreeBSD.ORG
Subject:   Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) 
Message-ID:  <28840.981407835@critter>
In-Reply-To: Your message of "Mon, 05 Feb 2001 13:09:54 PST." <Pine.LNX.4.21.0102051304200.2887-100000@zeppo.feral.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.LNX.4.21.0102051304200.2887-100000@zeppo.feral.com>, Matthew Jacob writes:
>
>All of this is nice and fine, but the take home notion here is that there's
>more  than a "maximum" or a "preferred" size. There's also a "required request
>size". And this isn't a constant value you can stash in a dev_t- or you'll
>have to have drivers change it as required.
>
>It seems to me that the physio should just be beefed up to take an argument to
>a 'parameterization' function, and that flags could be used that say "we don't
>even need this mapped any where- just make sure that the pages referred to are
>resident".

This is a different issue.  Yes, I want us to be able to handle
unmapped pages with struct bio, but that is an entirely separate
(and simpler) issue than how clustering is done.

To make struct bio handle unmapped memory, all you have to
do is this:

	1.  Add a driver flag which means "I can do unmapped
	    struct bio": D_UNMAPPEDBIO.

	2.  Add code to specfs::specstrategy():

		if (!(devsw(dev_t)->d_flags & D_UNMAPPEDBIO)) {
			if (bio_is_unmapped(bio))
				map_bio(bio);
		}

	3.  Add the fields you need to struct bio.

	4.  Write a driver which DTRT.

	5.  Make upper kernel and filesystems use the new facility.

By all means attack this if you have the foo it takes.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




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