On Fri, Sep 13, 2002 at 02:09:54PM -0700, Samuel Flory wrote:
> Andrea Arcangeli wrote:
>
> >
> >
> >you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to
> >(512 << 20) and see if it helps. If it only happens a bit later then
> >it's most probably an address space leak, should be easy to track down
> >some debugging instrumentation.
> >
> >
>
>
> It seems to be working for me now. I'm getting about 200 on dbench 4,
> and 90 on dbench 64. (Note you need to increase your log size to get
> these kinda of numbers.) Now I get to see how fast I can read files via
> nfs.
btw, if you run into troubles with networking with aa2 try to backout
the last net-softirq patch, not sure why yet but the last modification I
did malfunctions with some nic. Couldn't reproduce it here, but I'll
look into that next week and I'll fix it too for the next -aa.
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)
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:35 EST