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
[-- Attachment #1 --] On Wed, Aug 10, 2005 at 12:17:36AM +0000, Tor Egge wrote: +> tegge 2005-08-10 00:17:36 UTC +> +> FreeBSD src repository +> +> Modified files: +> sys/vm vm_object.c vm_pageout.c +> Log: +> Don't allow pagedaemon to skip pages while scanning PQ_ACTIVE or PQ_INACTIVE +> due to the vm object being locked. +> +> When a process writes large amounts of data to a file, the vm object associated +> 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, pagedaemon 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 belonging to +> other vm objects. +> +> Temporarily unlock the page queues lock while locking vm objects to avoid lock +> order violation. Detect and handle relevant page queue changes. +> +> This change depends on both the lock portion of struct vm_object and normal +> 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=/dev/zero of=/mnt/test bs=1m 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=12). ad0a.eli[WRITE(offset=4619829248, length=131072)] GEOM_ELI: Cannot allocate 136192 bytes. GEOM_ELI: g_eli_crypto_run() failed (error=12). ad0a.eli[WRITE(offset=4620746752, length=131072)] [...] 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. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC/QAfForvXbEpPzQRAk4FAKC+yR8RtJbyI15MaBFUFjSN0/dUNQCglji/ CZpN7rSD2WJoxRA2k6BMd4g= =L8Kj -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050812200136.GE27996>