Date: Fri, 12 Aug 2005 22:01:36 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Tor Egge <tegge@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_object.c vm_pageout.c Message-ID: <20050812200136.GE27996@garage.freebsd.pl> In-Reply-To: <200508100017.j7A0HaZE076905@repoman.freebsd.org> References: <200508100017.j7A0HaZE076905@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--DqhR8hV3EnoxUkKN Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 10, 2005 at 12:17:36AM +0000, Tor Egge wrote: +> tegge 2005-08-10 00:17:36 UTC +>=20 +> FreeBSD src repository +>=20 +> Modified files: +> sys/vm vm_object.c vm_pageout.c=20 +> Log: +> Don't allow pagedaemon to skip pages while scanning PQ_ACTIVE or PQ_IN= ACTIVE +> due to the vm object being locked. +> =20 +> When a process writes large amounts of data to a file, the vm object a= ssociated +> with that file can contain most of the physical pages on the machine. = If the +> process is preempted while holding the lock on the vm object, pagedaem= on would +> be able to move very few pages from PQ_INACTIVE to PQ_CACHE or from PQ= _ACTIVE +> to PQ_INACTIVE, resulting in unlimited cleaning of dirty pages belongi= ng to +> other vm objects. +> =20 +> Temporarily unlock the page queues lock while locking vm objects to av= oid lock +> order violation. Detect and handle relevant page queue changes. +> =20 +> This change depends on both the lock portion of struct vm_object and n= ormal +> struct vm_page being type stable. I'm not sure this fix the problem completely. I can still reproduce it with GELI, which is allocating in-kernel memory for every write request: # geli onetime -s 4096 ad0a # newfs /dev/ad0a.eli # mount /dev/ad0a.eli /mnt # dd if=3D/dev/zero of=3D/mnt/test bs=3D1m In top(1) output I see how memory goes down to few hundred kilo bytes and after some time I get: GEOM_ELI: Cannot allocate 136192 bytes. GEOM_ELI: g_eli_crypto_run() failed (error=3D12). ad0a.eli[WRITE(offset=3D4= 619829248, length=3D131072)] GEOM_ELI: Cannot allocate 136192 bytes. GEOM_ELI: g_eli_crypto_run() failed (error=3D12). ad0a.eli[WRITE(offset=3D4= 620746752, length=3D131072)] [...] There is no memory leak in GELI: # vmstat -m | grep eli eli data 2 1K - 5309 32,256,512,1024 It is much better than it was before your fix, but I think the problem still exist, it's only harder to run into. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --DqhR8hV3EnoxUkKN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC/QAfForvXbEpPzQRAk4FAKC+yR8RtJbyI15MaBFUFjSN0/dUNQCglji/ CZpN7rSD2WJoxRA2k6BMd4g= =L8Kj -----END PGP SIGNATURE----- --DqhR8hV3EnoxUkKN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050812200136.GE27996>