Date: Thu, 17 May 2001 23:20:23 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Rik van Riel <riel@conectiva.com.br>, Charles Randall <crandall@matchlogic.com>, Roger Larsson <roger.larsson@norran.net>, arch@FreeBSD.ORG, linux-mm@kvack.org, sfkaplan@cs.amherst.edu Subject: Re: on load control / process swapping Message-ID: <200105180620.f4I6KNd05878@earth.backplane.com> References: <Pine.LNX.4.33.0105161439140.18102-100000@duckman.distro.conectiva> <200105161754.f4GHsCd73025@earth.backplane.com> <3B04BA0D.8E0CAB90@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I don't understand how either of those things could help :but make overall performance worse. : :The problem is the program in question is seeking all :over the place, potentially multiple times, in order :to avoid building the table in memory itself. : :For many symbols, like "printf", it will hit the area :of the library containing their addresses many, many :times. : :The problem in this case is _truly_ that the program in :question is _really_ trying to optimize its performance :at the expense of other programs in the system. The linker is seeking randomly as a side effect of the linking algorithm. It is not doing it on purpose to try to save memory. Forcing the VM system to think it's sequential causes the VM system to perform read-aheads, generally reducing the actual amount of physical seeking that must occur by increasing the size of the chunks read from disk. Even if the linker's dataset is huge, increasing the chunk size is beneficial because linkers ultimately access the entire object file anyway. Trying to save a few seeks is far more important then reading extra data and having to throw half of it away. :The problem is what to do about this badly behaved program, :so that the system itself doesn't spend unnecessary time :undoing its evil, and so that other (well behaved) programs :are not unfairly penalized. : :Cutler suggested a working set quota (first in VMS, later :in NT) to deal with these programs. : :-- Terry The problem is not the resident set size, it's the seeking that the program is causing as a matter of course. Be that as it may, the resident set size can be limited with the 'memoryuse' sysctl. The system imposes the specified limit only when the memory subsystem is under pressure. You can also reduce the amount of random seeking the linker does by ordering the object modules within the library to forward-reference the dependancies. -Matt 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?200105180620.f4I6KNd05878>