|To:||Andi Kleen <ak@xxxxxxx>|
|From:||Samuel Flory <sflory@xxxxxxxxxxxx>|
|Date:||Sun, 15 Sep 2002 12:39:20 -0700|
|Cc:||Stephen Lord <lord@xxxxxxx>, Andrea Arcangeli <andrea@xxxxxxx>, Austin Gonyou <austin@xxxxxxxxxxxxxxx>, Christian Guggenberger <christian.guggenberger@xxxxxxxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx|
|References:||<20020911184111.GY17868@xxxxxxxxxxxxxxxxx> <3D81235B.6080809@xxxxxxxxxxxx> <20020913002316.GG11605@xxxxxxxxxxxxxxxxx> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@xxxxxxxxxxxxxxxxx> <3D8149F6.9060702@xxxxxxxxxxxx> <20020913125345.GO11605@xxxxxxxxxxxxxxxxx> <3D825422.8000007@xxxxxxxxxxxx> <20020913211844.GP11605@xxxxxxxxxxxxxxxxx> <1032014367.1050.2.camel@xxxxxxxxxxxxxxxxxxxxxxx> <20020915131324.A13516@xxxxxxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826|
Andi Kleen wrote:
On Sat, Sep 14, 2002 at 09:39:24AM -0500, Steve Lord wrote:On Fri, 2002-09-13 at 16:18, Andrea Arcangeli wrote:So, returning to xfs, it is possible dbench really generates lots of simultaneous vmaps because of its concurrency, so I would suggest to add an atomic counter increased at every vmap/vmalloc and decreased at every vfree and to check it after every increase storing the max value in a sysctl, to see what's the max concurrency you reach with the vmaps. (you can also export the counter via the sysctl, to verify for no memleaks after unmounting xfs) AndreaThere are no vmaps during normal operation on xfs unless you are setting extended attributes of more than 4K in size, or you used some more obscure mkfs options. Only filesystem recovery willuse it otherwise.Perhaps the original poster used those obscure mkfs options? What optionwill trigger huge allocations ?
I did not use any special options on the filesystem that had the issue.
|<Prev in Thread]||Current Thread||[Next in Thread>|