Date: Thu, 29 Sep 2005 02:03:22 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: phk@phk.freebsd.dk Cc: current@FreeBSD.org Subject: Re: stress test deadlock involving vm and/or geom Message-ID: <200509290903.j8T93MRl007148@gw.catspoiler.org> In-Reply-To: <7056.1127979248@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Sep, Poul-Henning Kamp wrote:
> In message <200509290731.j8T7V2OR007019@gw.catspoiler.org>, Don Lewis writes:
>
>>(kgdb) print runningbufspace
>>$3 = 1585152
>>(kgdb) print lorunningspace
>>$4 = 524288
>>print hirunningspace
>>$5 = 1048576
>>
>>so runningbufspace >> hirunningspace
>>
>>The bufdaemon and the syncer both ignore the runningbufspace limit.
>>Maybe they should obey the limit, but each be guaranteed a minimum
>>quota.
>
> I'm not quite sure what a/the sensible solution is, but the
> lemming-syncer certainly is my prime suspect.
It's probably not helping things. On the other hand, 1.5 MB of
in-flight I/O doesn't sound like a lot now that disks commonly have 8MB
caches and there may be multiple drives in the system.
Hmn, vmstat -s says 0 pages, free, which probably going to cause
problems ...
201909 pages active
24736 pages inactive
0 pages in VM cache
28573 pages wired down
0 pages free
Looks like something is gobbling the last of the free memory faster than
we can react. I'm running the test again and according to top the free
memory seems to stabilize at a minimum of 1656K.
Maybe we need to get more aggressive about not handing out memory pages
when the pagedaemon runs out of pbufs.
There may also just be too much transient kmem demand when snapshots
are created or removed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509290903.j8T93MRl007148>