Date: Wed, 16 May 2001 10:54:12 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Rik van Riel <riel@conectiva.com.br> Cc: Charles Randall <crandall@matchlogic.com>, Roger Larsson <roger.larsson@norran.net>, <arch@FreeBSD.ORG>, <linux-mm@kvack.org>, <sfkaplan@cs.amherst.edu> Subject: Re: RE: on load control / process swapping Message-ID: <200105161754.f4GHsCd73025@earth.backplane.com> References: <Pine.LNX.4.33.0105161439140.18102-100000@duckman.distro.conectiva>
next in thread | previous in thread | raw e-mail | index | archive | help
: :There's one thing "wrong" with the drop-behind idea though; :it penalises data even when it's still in core and we're :reading it for the second or third time. It's not dropping the data, it's dropping the priority. And yes, it does penalize the data somewhat. On the otherhand if the data happens to still be in the cache and you scan it a second time, the page priority gets bumped up relative to what it already was so the net effect is that the data becomes high priority after a few passes. :Maybe it would be better to only do drop-behind when we're :actually allocating new memory for the vnode in question and :let re-use of already present memory go "unpunished" ? You get an equivalent effect even without dropping the priority, because you blow away prior pages when reading a file that is larger then main memory so they don't exist at all when you re-read. But you do not get the expected 'recycling' characteristics verses the rest of the system if you do not make a distinction between sequential and random access. You want to slightly depress the priority behind a sequential access because the 'cost' of re-reading the disk sequentially is nothing compared to the cost of re-reading the disk randomly (by about a 30:1 ratio!). So keeping randomly seek/read data is more important by degrees then keeping sequentially read data. This isn't to say that it isn't important to try to cache sequentially read data, just that the cost of throwing away sequentially read data is much lower then the cost of throwing away randomly read data on a general purpose machine. Terry's description of 'ld' mmap()ing and doing all sorts of random seeking causing most UNIXes, including FreeBSD, to have a brainfart of the dataset is too big to fit in the cache is true as far as it goes, but there really isn't much we can do about that situation 'automatically'. Without hints, the system can't predict the fact that it should be trying to cache the whole of the object files being accessed randomly. A hint could make performance much better... a simple madvise(... MADV_SEQUENTIAL) on the mapped memory inside LD would probably be beneficial, as would madvise(... MADV_WILLNEED). -Matt :Hmmm, now that I think about this more, it _could_ introduce :some different fairness issues. Darn ;) : :regards, : :Rik 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?200105161754.f4GHsCd73025>