lkml.org 
[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.20pre5aa2
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/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.148 / U:1.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site