Memory leak on thread removal
Hi,
The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386, amd64):
#include omp.h
#include unistd.h
int n = 4, m = 2;
int main () {
for (;;) {
int i;
//sleep(2);
#pragma omp parallel for num_threads(m)
for(i = 0; i 1; i++) {}
//sleep(2);
#pragma omp parallel for num_threads(n)
for(i = 0; i 1; i++) {}
}
return 0;
}
During the run the program's virtual memory usage constantly grows. The growth
is observed only when n != m. When running the program with uncommented
sleep() and observing the number of threads with 'top -H' I see in turn 2 or 4
threads. So it looks like memory leak when thread is removed. Should I fill
PR?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Kernel Conference Australia 2009 - registrations and agenda pages NOW LIVE
Dear friends, It gives me great pleasure to announce that registrations for Kernel Conference Australia 2009 are now open, at http://au.sun.com/sunnews/events/2009/kernel/ The confirmed agenda and the speaker bio pages are here: http://au.sun.com/sunnews/events/2009/kernel/agenda.jsp http://au.sun.com/sunnews/events/2009/kernel/speakers.jsp I'm looking forward to seeing you there. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to invalidate NFS read cache?
On Fri, 8 May 2009, Konrad Heuer wrote: sporadically, I observe a strange but serious problem in our large NFS environment. NFS servers are Linux and OS X with StorNext/Xsan cluster filesystems, NFS clients Linux and FreeBSD. NFS client A changes a file, but nfs client B (running on FreeBSD) does still see the old version. On the NFS server itself, everything looks fine. Afaik the FreeBSD kernel invalidates the NFS read cache if file modification time on the server changed which should happen here but doesn't. Can I force FreeBSD (e.g. by sysctl setting) to read file buffers again unconditionally after vfs.nfs.access_cache_timeout seconds have passed? Hi Konrad: Normally, NFS clients implement open-to-close consistency, which dictates that when a close() occurs on client A, all pending writes on the file should be issued to the server before close() returns, so that a signal to client B to open() the file can validate its cache before open() returns. This raises the following question: is client A closing the file, and is client B then opening it? If not: relying on writes being visible on the client B before the close() on A and a fresh open() on B is not guaranteed to work, although we can discuss ways to improve behavior with respect to expectation. Try modifying your application and see if it gets the desired behavior, and then we can discuss ways to improve what you're seeing. If you are: this is probably a bug in our caching and or issuing of NFS RPCs. We cache both attribute and access data -- perhaps there is an open() path where we issue neither RPC? In the case of open, we likely should test for a valid access cache entry, and if there is one, issue an attribute read, and otherwise just issue an access check which will piggyback fresh attribute data on the reply. Perhaps there is a bug here somewhere. A few other misc questions: - Could you confirm you're using NFSv3 on all clients. Are there any special mount options in use? - What version of FreeBSD are you running with? In FreeBSD 8.x, we now have DTrace probes for all of the above events -- VOPs, attribute cache hit/miss/load/flush, access cache hit/miss/load/flush, RPCs, etc, which we can use to debug the problem. I haven't yet MFC'd these to 7.x, but if you're able to run a very fresh 7-STABLE, I can probably produce a patch to add it for you in a few days. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to invalidate NFS read cache?
On Tue, 12 May 2009, Robert Watson wrote: Normally, NFS clients implement open-to-close consistency, which dictates that when a close() occurs on client A, all pending writes on the file should be issued to the server before close() returns, so that a signal to client B to open() the file can validate its cache before open() returns. This should, of course, read close-to-open consistency -- I plead jetlag after an overnight flight back form Boston to the UK :-) Robert N M Watson Computer Laboratory University of Cambridge This raises the following question: is client A closing the file, and is client B then opening it? If not: relying on writes being visible on the client B before the close() on A and a fresh open() on B is not guaranteed to work, although we can discuss ways to improve behavior with respect to expectation. Try modifying your application and see if it gets the desired behavior, and then we can discuss ways to improve what you're seeing. If you are: this is probably a bug in our caching and or issuing of NFS RPCs. We cache both attribute and access data -- perhaps there is an open() path where we issue neither RPC? In the case of open, we likely should test for a valid access cache entry, and if there is one, issue an attribute read, and otherwise just issue an access check which will piggyback fresh attribute data on the reply. Perhaps there is a bug here somewhere. A few other misc questions: - Could you confirm you're using NFSv3 on all clients. Are there any special mount options in use? - What version of FreeBSD are you running with? In FreeBSD 8.x, we now have DTrace probes for all of the above events -- VOPs, attribute cache hit/miss/load/flush, access cache hit/miss/load/flush, RPCs, etc, which we can use to debug the problem. I haven't yet MFC'd these to 7.x, but if you're able to run a very fresh 7-STABLE, I can probably produce a patch to add it for you in a few days. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: POSIXfy readlink() call
On Mon, May 11, 2009 at 04:23:52PM -0400, John Baldwin wrote: On Monday 11 May 2009 2:58:14 pm Kostik Belousov wrote: On Mon, May 11, 2009 at 02:46:14PM -0400, John Baldwin wrote: On Monday 11 May 2009 2:33:09 pm Kostik Belousov wrote: On Mon, May 11, 2009 at 02:05:07PM -0400, John Baldwin wrote: On Friday 28 September 2007 10:39:56 pm Ighighi wrote: ^ Yes, I had this stuck in the back of my head from when it first appeared. The POXIX prototype for readlink(2) is: ssize_t readlink(const char *restrict path, char *restrict buf, size_t bufsize); It can't simply be corrected as it would change the ABI and thus requires a new system call, etc. However, do you really expect a symlink to be longer than 2^31 on a 64-bit machine? Yes, I agree that this is ABI change. Meantime, r176215 | ru | 2008-02-12 22:09:04 +0200 (Tue, 12 Feb 2008) | 5 lines Change readlink(2)'s return type and type of the last argument to match POSIX. Prodded by: Alexey Lyashkov I tried to convince ru@ that ABI breakage is not good, but has not succeeded. Ugh, is this only in HEAD? If so, I will back it out for 8.0. If this made it into a release then this is a far bigger mess. Oh, good, this is only in 8. I will fix this ASAP. I can just add the new syscall I guess. You need to symver the syscalls. It requires some ugly games with our syscall stubs, because gnu ld only honor .symver in the same object where the symbol is defined. I did prototyped this some time ago, by including a file with appropriate .symver from all stubs. So, after thinking about this out loud some more, it seems the ABI breakage would only be for 64-bit platforms that passed a -ve value as the buffer size. However, doing so would already either panic due to triggering an assertion, or result in otherwise undefined behavior and that making the new parameter unsigned actually results in the same undefined behavior in the non-panic case. For the record. I also suggest (re-)reading a thread http://lists.freebsd.org/pipermail/freebsd-current/2008-February/thread.html#83314 that resulted from the original commit where I try to make it clear that a scary ABI breakage Konstantin mentions is pure artificial. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
