Re: L1 cache thrashing affects performance of HIMENO benchmark
On Jan 5, 2013, at 12:47 PM, Adrian Chadd adr...@freebsd.org wrote: On 5 January 2013 07:38, Hakisho Nukama nuk...@gmail.com wrote: FreeBSD (PCBSD) is slower compared to Linux and kFreeBSD in this benchmark of HIMENO: http://openbenchmarking.org/prospect/1202215-BY-FREEBSD9683/88ac7a01c6cb355d7e7603224b2ee1e5a4cb881d Also DragonFly BSD compares worse to kFreeBSD and Linux: http://www.phoronix.com/scan.php?page=articleitem=dragonfly_linux_32num=3 http://openbenchmarking.org/prospect/1206255-SU-DRAGONFLY55/88ac7a01c6cb355d7e7603224b2ee1e5a4cb881d Matt, Venkatesh and Alex investigated this performance problem and came to these results: http://leaf.dragonflybsd.org/mailarchive/users/2013-01/msg00011.html I've CC'ed jasone on this as it's an interesting side-effect of memory allocation logic. Jason - any comments? There are many variations on this class of performance problem, and the short of it is that only the application can have adequate understanding of data structure layout and access patterns to reliably make optimal use of the cache. However, it is possible for the allocator to lay out memory in a more haphazard fashion than jemalloc, phkmalloc, etc. do, such that the application can be cache-oblivious and (usually) not suffer worst case consequences as happened in this case. Extent-based allocators like dlmalloc often get this for free for a significant range of allocation sizes. jemalloc could be modified to this end, but a full solution would necessarily increase internal fragmentation. It might be worth experimenting with nonetheless. Thanks, Jason ___ 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: malloc+utrace, tracking memory leaks in a running program.
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein bri...@mu.org wrote: So the other day in an effort to debug a memory leak I decided to take a look at malloc+utrace(2) and decided to make a tool to debug where leaks are coming from. A few hours later I have: 1) a new version of utrace(2) (utrace2(2)) that uses structured data to prevent overloading of data. (utrace2.diff) 2) changes to ktrace and kdump to decode the new format. (also in utrace2.diff) 3) changes to jemalloc to include the new format AND the function caller so it's easy to get the source of the leaks. (also in utrace2.diff) 4) a program that can take a pipe of kdump(1) and figure out what memory has leaked. (alloctrace.py) 5) simple test program (test_utrace.c) […] Have you looked at the heap profiling functionality built into jemalloc? It's not currently enabled on FreeBSD, but as far as I know, the only issue keeping it from being useful is the absence of a Linux-compatible /proc/pid/maps (and the gperftools folks may already have a solution for that; I haven't looked). I think it makes more sense to get that sorted out than to develop a separate trace-based leak checker. The problem with tracing is that it doesn't scale beyond some relatively small number of allocator events. Is it time to start installing with some form of debug symbols? This would help us also with dtrace. Re: debug symbols, frame pointers, etc. necessary to make userland dtrace work by default, IMO we should strongly prefer such defaults. It's more reasonable to expect people who need every last bit of performance to remove functionality than to expect people who want to figure out what the system is doing to figure out what functionality to turn on. Thanks, Jason ___ 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: heap limits: mmap(2) vs. break(2) on i386
Maxim Sobolev wrote: I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Some memory (1GiB?) is reserved for kernel address space, and you reserved 2GiB for DSS. That leaves less than 1GiB available after shared libraries and whatnot are mapped. If there is more than 1GiB available, mmap can still fail due to the memory being non-contiguous. Jason ___ 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: heap limits: mmap(2) vs. break(2) on i386
Maxim Sobolev wrote: Jason Evans wrote: Maxim Sobolev wrote: I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Some memory (1GiB?) is reserved for kernel address space, and you reserved 2GiB for DSS. That leaves less than 1GiB available after shared libraries and whatnot are mapped. If there is more than 1GiB available, mmap can still fail due to the memory being non-contiguous. So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself less than 1GB left to be allocated via mmap()? Yes, my recollection is that MAXDSIZ controls the amount of virtual address space dedicated to DSS, and this address space will not be mapped via anonymous mmap. I wanted to move completely away from using sbrk in malloc, but we can't completely remove DSS for backward compatibility reasons, which means less heap address space than would be ideal. What is the best strategy if I want to maximize amount of memory available to applications? Most of modern applications use mmap(), isn't it? Then where MAXDSIZ can bite me if I set it to say 512MB? I would set MAXDSIZ to 0, so that the maximum amount of memory is available for mapping shared libraries and files, and allocating via malloc. This may cause problems with a couple of ports that implement their own memory allocators based on sbrk, but otherwise it should be all good. You might also set /etc/malloc.conf to 'd' in order to disable the sbrk calls. Jason ___ 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: Zero-length allocation with posix_memalign()
Fabian Keil wrote: Rémi Denis-Courmont, one of the vlc developers, pointed out that passing a zero size to posix_memalign() should actually work, though: | In principle, while useless, there is no reason why allocating an empty | picture should not be possible. posix_memalign() does support zero-length | allocation anyway: | http://www.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html | | If the size of the space requested is 0, the behavior is | | implementation-defined; the value returned in memptr shall be either a | | null pointer or a unique pointer. Standards: So many to choose from. This behavior for posix_memalign was only defined as of the 2008 standard (see the Issue 7 notes for posix_memalign): https://www.opengroup.org/austin/interps/uploads/40/14543/AI-152.txt Such requirements are unfortunate, because they induce a performance penalty for every call, just so that programs can avoid proper handling of edge cases in the rare situations for which such edge cases are a real possibility. I will add the pessimization to posix_memalign once the 8.0 freeze is over. It will be quite some time before this behavior becomes ubiquitous, so in the meanwhile it's probably a good idea to modify vlc to avoid such allocation requests. Thanks, Jason ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
Robert Watson wrote: On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org, Robert Wats on writes: In which case user application threads will need to know their CPU [...] Didn't jemalloc solve that problem once already ? I think jemalloc implements thread-affinity for arenas rather than CPU-affinity in the strict sense, but I may misread. CPU affinity is of limited use to malloc unless it can safely pin threads to CPUs. Unfortunately, malloc cannot muck with CPU affinity, since that's up to the application. Therefore, as you say, jemalloc implements (dynamically balanced) arena affinity. It might work okay in practice to use the current CPU ID to decide which arena to use, if the scheduler does not often migrate running processes. I haven't explored that possibility though, since the infrastructure for cheaply querying the CPU ID doesn't currently (to my knowledge) exist. Jason ___ 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: threaded, forked, rethreaded processes will deadlock
Brian Fundakowski Feldman wrote: Could you, and anyone else who would care to, check this out? It's a regression fix but it also makes the code a little bit clearer. Thanks! Index: lib/libc/stdlib/malloc.c Why does malloc need to change for this? Unless there's a really good reason, I don't want the extra branches in the locking functions. Thanks, Jason ___ 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: unexpected behaviour of malloc() on 7.0/amd64
Andrew MacIntyre wrote: In investigating a Python 2.6rc1 regression test failure on FreeBSD 7.0/amd64, as far as I can tell, malloc() does not return NULL when available memory (including swap) is exhausted - the process just gets KILLed. Using ulimit -v to set a virtual memory use limit below the available memory does result in malloc() returning NULL when the limit is hit. The Python regression test concerned does not fail on FreeBSD 7.0/i386, however the C program below exhibits the unexpected behaviour on both 7.0/amd64 and 7.0/i386. The C program below does behave as expected on FreeBSD 6.3/i386; I cannot currently test its behaviour on FreeBSD 6.3/amd64. I can't see this behaviour documented in the malloc() man page. From malloc(3): === IMPLEMENTATION NOTES Traditionally, allocators have used sbrk(2) to obtain memory, which is suboptimal for several reasons, including race conditions, increased fragmentation, and artificial limitations on maximum usable memory. This allocator uses both sbrk(2) and mmap(2) by default, but it can be configured at run time to use only one or the other. If resource limits are not a primary concern, the preferred configuration is MALLOC_OPTIONS=dM or MALLOC_OPTIONS=DM. When so configured, the datasize resource limit has little practical effect for typical applications; use MALLOC_OPTIONS=Dm if that is a concern. Regardless of allocator configuration, the vmemoryuse resource limit can be used to bound the total virtual memory used by a process, as described in limits(1). === If you want a custom python binary that does not use mmap, you can define _malloc_options to d, or just use MALLOC_OPTIONS in the environment. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unexpected behaviour of malloc() on 7.0/amd64
Andrew MacIntyre wrote: However my reading of the updated man page suggests that the malloc options string should be Dm or m to turn off mmap() and only use sbrk() - could you clarify why d? Whoops, I meant m, not d. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dlopen(), atexit() crash on FreeBSD (testcase included)
Markus Hoenicka wrote: I've been redirected by Giorgos Keramidas to this list after reporting a problem on the freebsd-questions list. I'd greatly appreciate if you could have a look at the following problem. Apparently programs are doomed to segfault on FreeBSD if dlopen()ed modules install exit handlers via atexit(). Similar problem reports have cropped up before, It seems to me that you should *expect* a crash under the circumstances you describe. You are dlopen()ing a module, saving a pointer to a function within that module, unloading the module, then trying to call a function that is no longer mapped. The only way this could possibly work is if dlclose() doesn't really unmap the module. It is up to the programmer to avoid dangling pointers to unmapped modules. There are all sorts of variations on this bug, such as storing a pointer to a const string. You have to be really careful to be able to safely dlclose() a module. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: assertion failed on malloc.c
Pietro Cerutti wrote: uname -r 8.0-CURRENT Mplayer always crashes quitting .flv video (either by pressing 'q' or because the video is over). The error is: Assertion failed: (diff == regind * size), function arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 1714. Removing the assert at line 1714 and recompiling libc solves the problem, but I'm not that familiar with the current malloc implementation to know whether (diff == regind * size) is always supposed to be true (thus a bug in mplayer) or the assertion is simply wrong. This is probably due to attempted deallocation of an invalid pointer. This could be either a double free or a totally bogus deallocation, perhaps of a pointer that is within a valid object. Removing the assertion in malloc.c simply allows undefined behavior beyond where the assertion failure would have caused a crash. The failure modes can be serious, such as memory corruption or a segmentation fault. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Inner workings of turnstiles and sleepqueues
Ed Schouten wrote: For some reason, I want to understand how the queueing of blocked threads in the kernel works when waiting for a lock, which is if I understand correctly done by the turnstiles and sleepqueues. I'm the proud owner of The Design and Implementation of the FreeBSD Operating System book, but for some reason, I can't find anything about it in the book. Is there a way to obtain information about how they work? I already read the source somewhat, but that shouldn't be an ideal solution, in my opinion. You might take a look at _Solaris Internals_ by Mauro and McDougall. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The optimization of malloc(3): FreeBSD vs GNU libc
李鑫 (LI Xin) wrote: 在 2006-08-15二的 02:38 +0300，Vladimir Kushnir写道： On -CURENT amd64 (Athlon64 3000+, 512k L2 cache): With jemalloc (without MY_MALLOS): ~/fdtd /usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 116.34 real 113.69 user 0.00 sys With MY_MALLOC: ~/fdtd /usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 45.30 real44.29 user 0.00 sys Have you turned off the debugging options, i.e. ln -sf 'aj' /etc/malloc.conf? If you want to do a fair comparison, you will also define NO_MALLOC_EXTRAS when compiling malloc.c, in order to turn off the copious assertions, not to mention the statistics gathering code. Before you do that though, it would be useful to turn statistics reporting on (add MALLOC_OPTIONS=P to your environment when running the test program) and see what malloc says is going on. [I am away from my -current system at the moment, so can't benchmark the program.] If I understand the code correctly (and assuming the command line parameters specified), it starts out by requesting 3517 2000-byte allocations from malloc, and never frees any of those allocations. Both phkmalloc and jemalloc will fit two allocations in each page of memory. phkmalloc will call sbrk() at least 1759 times. jemalloc will call sbrk() approximately 6 times. 2kB allocations are a worst case for some of jemalloc's internal bookkeeping, but this shouldn't be a serious problem. Fragmentation for these 2000-byte allocations should total approximately 6%. malloc certainly incurs more overhead than a specialized sbrk()-based allocator, but I don't see any particular reason that jemalloc should perform suboptimally, as compared to any complete malloc implementation, for fdtd. If you find otherwise, please tell me so that I can look into the issue. Thanks, Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Porting libumem (was Re: Is anyone working on a port of ZFS to FreeBSD)
[EMAIL PROTECTED] wrote: IMHO, and purely as constructive criticism, Jason's article would've been much more interesting if he had tested ptmalloc (in the ports tree) and we had had libumem. Yes, that would have been nice, but when I tried to use ptmalloc, it failed to work correctly. I don't remember the details anymore, but ISTR there was something wrong with the ptmalloc port that I didn't have the time to fix. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unsatisfying c++/boost::multi_index_container::erase performance on at least FreeBSD 6.0
bert hubert wrote: Thanks Jason, this has helped narrow down the problem significantly. From this I understand that to work around this problem, I have some options: 1) tweak my code to not allocate such a large amount of small objects 2) move away from malloc/free based c++ allocators 3) recompile libc with jemalloc I'm really hoping for 4) where I can LD_PRELOAD only jemalloc, would that be possible? Or does libc include parts of malloc/free itself inlined? I'd hate to force PowerDNS users to recompile their libc for me :-) Yes, you should be able to use LD_PRELOAD to pre-load a shared library that has nothing but malloc.o in it. In order to build jemalloc on 6.x, you will also need sys/tree.h from -current. If you are using pthreads on an SMP system, you will either need to increase the number of libc spinlocks in libpthread, or use MALLOC_OPTIONS to make sure that a small enough number of arenas is used. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unsatisfying c++/boost::multi_index_container::erase performance on at least FreeBSD 6.0
bert hubert wrote: Dear FreeBSD hackers, I'm working on improving the PowerDNS recursor for a big FreeBSD-loving internet provider in The Netherlands and I am hitting some snags. I also hope this is the appropriate list to share my concerns. Pruning the cache is very very slow on the providers FreeBSD 6.0 x86 systems whereas it flies on other operating systems. I've managed to boil down the problem to the code found on http://ds9a.nl/tmp/cache-test.cc which can be compiled with: 'g++ -O3 -I/usr/local/include cache-test.cc -o cache-test' after installing Boost from the ports. The problem exists both with the system compiler and with a self-compiled g++ 4.1. Here are some typical timings: $ ./cache-test Creating.. Copying 499950 nodes 100 345 usec3.45 usec/erase 300 3298 usec 10.99 usec/erase 500 8749 usec 17.50 usec/erase 700 72702 usec 103.86 usec/erase 900 46521 usec 51.69 usec/erase On another operating system with almost the same cpu: $ ./cache-test Creating.. Copying 499950 nodes 100 62 usec 0.62 usec/erase 300 187 usec0.62 usec/erase 500 347 usec0.69 usec/erase 700 419 usec0.60 usec/erase 900 575 usec0.64 usec/erase I've toyed with MALLOC_OPTIONS, especially the options, I've tried GLIBCXX_FORCE_NEW, I've tried specifying a different STL allocator in the c++ code, it all doesn't change a thing. A quick gprof profile shows a tremendous number of calls to 'ifree' but that may be due to the copying of the container going on between test runs. Any help would be very appreciated as I am all out of clues. Thanks. I ran cache-test on -current using phkmalloc and a couple of different versions of jemalloc. jemalloc does not appear to have the same issue for this test. It isn't obvious to me why phkmalloc is performing so poorly, but I think you can assume that this is a malloc performance problem. The following jemalloc results were run with NO_MALLOC_EXTRAS defined. I included the patch results because I expect to commit the patch this week. phkmalloc and jemalloc have similar memory usage, but jemalloc is substantially faster. The jemalloc patch uses substantially less memory than either phkmalloc or jemalloc. Jason --- phkmalloc: - onyx:~ MALLOC_OPTIONS=aj LD_PRELOAD=/tmp/phkmalloc/libc/libc.so.6 =time -l ./cache-test Creating.. Copying 499950 nodes 100 501 usec5.01 usec/erase 300 53183 usec 177.28 usec/erase 500 5491 usec 10.98 usec/erase 700 158989 usec 227.13 usec/erase 900 47491 usec 52.77 usec/erase 1100 324948 usec 295.41 usec/erase 1300 106480 usec 81.91 usec/erase 1500 522414 usec 348.28 usec/erase 1700 155604 usec 91.53 usec/erase 1900 685235 usec 360.65 usec/erase 2100 230939 usec 109.97 usec/erase 2300 860083 usec 373.95 usec/erase 2500 234910 usec 93.96 usec/erase 2700 1226310 usec454.19 usec/erase 2900 205739 usec 70.94 usec/erase 3100 1379395 usec444.97 usec/erase 3300 296925 usec 89.98 usec/erase 3500 1620705 usec463.06 usec/erase 3700 312343 usec 84.42 usec/erase 3900 1835125 usec470.54 usec/erase 4100 306443 usec 74.74 usec/erase 4300 1805999 usec420.00 usec/erase 4500 323179 usec 71.82 usec/erase 4700 1593007 usec338.94 usec/erase 4900 316249 usec 64.54 usec/erase 495.53 real 494.29 user 1.17 sys 279240 maximum resident set size 60 average shared memory size 274524 average unshared data size 128 average unshared stack size 78238 page reclaims 1 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 4 voluntary context switches 6492 involuntary context switches --- jemalloc (-current):
Re: Solaris libumem port on the works
John-Mark Gurney wrote: That's why I started work on rewriting a allocated based upon the paper so that it'd have a BSD license... I haven't worked on it much, and now that jemalloc is here, who knows... Are you referring to the 2001 Usenix paper by Bonwick and Adams? That paper is a very interesting read, and I'm convinced that their work is very useful for a range of resource management problems. However, that paper does not provide enough benchmarking information for general conclusions regarding userland malloc (libumem) performance. libumem is based on a highly abstracted resource management algorithm, and as a result it has extra layers that are unnecessary for a userland malloc. I expect this to make libumem somewhat subpar for most real workloads. The following article provides some supporting evidence: http://developers.sun.com/solaris/articles/multiproc/multiproc.html Note though that the benchmarks in that article also fall far short of providing conclusive evidence regarding relative performance of the tested allocators. (Definitive malloc benchmarking is Hard.) Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Which signal occurs due to a page protection violation?
On Jan 31, 2006, at 1:06 AM, Sam Lawrance wrote: ElectricFence is failing during its self test on i386 7-current: Testing Electric Fence. After the last test, it should print that the test has PASSED. EF_PROTECT_BELOW= EF_PROTECT_FREE= EF_ALIGNMENT= ./eftest Segmentation fault (core dumped) *** Error code 139 The program intentionally overruns and underruns buffers in order to test the functionality of ElectricFence. I think it's failing because: 1) the new jemalloc is actually catching the problem and throwing SIGSEGV 2) ElectricFence is being compiled with - DPAGE_PROTECTION_VIOLATED_SIGNAL=SIGBUS on that platform. I'm not sure about this, but I think the change of which signal occurs is unrelated to jemalloc. I think Kris Kennaway at one point told me that jemalloc broke the efence port, but then later retracted that claim when efence also failed on a machine that was still using phkmalloc. This may be due to a signal delivery bugfix that someone put in, probably in early December 2005. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changes from 5.2.1 to 5.3 (theads / signal handling)
On Jan 26, 2006, at 12:55 AM, Jose Marcio Martins da Cruz wrote: Can you point me a good doc about threads, signals, and such kind of things in FreeBSD context ? David Butenhof's book, Programming with POSIX Threads, includes a good discussion of signals in the context of pthreads. How to avoid the problems you have been experiencing is covered in that book. If you haven't read the book, I highly recommend that you do so. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linking libc before libc_r into application causes weird problems
On Fri, Feb 08, 2002 at 07:46:34AM +0200, Maxim Sobolev wrote: Hi, When working on updating port of Ximian Evolution to the latest released version I have stuck to the problem - the new version of application just hanged on startup on my 5-CURRENT box. After lot of digging and debugging I found that the source of the problem is that the resulting application had libc linked in before libc_r, which caused waitpid() in the ORBit library just hang forever, even though child process died almost instantly (I see zombie in the ps(1) output). When program was relinked with -pthread flag, which seemingly forcing right order of libc/libc_r (libc_r first) the problem disappeared. Based on the problematic code in the ORBit I had prepared short testcase illustrating the problem and attaching it with this message. The problem could be exposed by compiling the test.c using the following command: $ cc test.c -o test -lc -lc_r When either of -lc or -lc_r is omitted, or their order is reversed the problem disappears. The problem doesn't exist on 4-STABLE. Any ideas, comments and suggestions are welcome. IIRC, Dan changed things in -current about six months ago so that -lc_r would do the right thing. Previously (and still in -stable), -pthread was necessary in order to prevent libc from being implicitly linked in. There's some magic in the compiler front end that prevents libc from being implicitly linked in if libc_r is specified. It may re-order things as well, but I'd have to look at the code to verify that. In any case, don't manually specify both, or Bad Things will happen, as you've discovered. It's my hope that we'll be able to use -lpthread by the 5.0 release, which is what the standards say should work. We could have that right now, but we've been holding off, since threads may be KSE-based by the 5.0 release. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A question about multithreaded server
The typical solution is to create a pipe, and write a byte to it in order to wake up the manager thread. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: AIO issues... or not?
On Fri, Oct 05, 2001 at 02:19:58PM +, E.B. Dreger wrote: However, there's a rather ominous and non-descriptive warning present: There are numerous stability issues in the current aio code that make it unsuitable for inclusion on shell boxes. Can anyone please elaborate? Is this admonition outdated? Seen on 4.3-R. Alan Cox has done a lot of work to make aio stable over the past year, and I'm guessing that it's reasonably stable as of 4.2 or 4.3. That warning can likely be removed. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [PATCH] Change lockmgr() to not recursively panic
On Wed, Aug 08, 2001 at 11:17:38AM -0700, Julian Elischer wrote: not from me, though you might say why you want this.. I think the reason was in the Subject line: Subject: [PATCH] Change lockmgr() to not recursively panic Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SMP Project Status (24 January 2001)
A lot of good progress has been made on the SMP project in the past couple of weeks. We are on the verge of being able to move portions of the kernel out of under the Giant lock, which will be the first improvement in performance due to our work, following a long string of developments over the past 6 months that actually (temporarily) decreased performance. John Baldwin is in the process of committing changes that lock accesses to the proc structure. This allows a number of system calls to run without holding Giant, as well as most signal handling. Additionally, a number of other system calls can be made MP-safe with only a moderate amount of additional effort. Jake Burkholder is in the late stages of testing changes that will make the kernel preemptive. As mentioned in the last status report, a number of other tasks hinge on this development. Bosko Milekic has made some important cleanups to mutexes with regard to recursion, and is in the process of completely revamping the mutex API and code structure (converting to non-inlined functions). Dag-Erling Smorgrav has joined the fray and made the zone allocator MP-safe. He has also expressed interest in doing further work locking the VM. Peter Wemm has been a huge help testing and debugging changes with at least John, Jake, and me. I finally committed Jake's condition variable implementation, and completely removed simplelocks from the kernel. Hopefully the sx lock implementation will be committed soon as well. The SMP project page is still at: http://people.freebsd.org/~jasone/smp/ The previous status email can be found at: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=45111+48223+/usr/local/www/db/text/2001/freebsd-smp/20010114.freebsd-smp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb threaded application
On Mon, Nov 06, 2000 at 01:33:21AM +1000, [EMAIL PROTECTED] wrote: Hi, I have a program compiled with -pthread and I'm trying to use gdb to debug it. I run the program in one window and then try to attach to it from another. I have put a sleep 10 in the program so I can catch it before it enters the section I want to debug. This is what I get: Attaching to program: /usr/home/andrew/work/msgs2/msgs, process 10063 Reading symbols from /usr/lib/libc_r.so.4...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. 0x280b7368 in _thread_sys_poll () from /usr/lib/libc_r.so.4 ^^^ For reasons that I don't entirely understand, using gdb with dynamically linked applications usually produces very undesireable (often totally incorrect) results on FreeBSD. I don't know that this is the problem, but the first thing I'd do if I were you would be to link statically. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Mon, Apr 24, 2000 at 04:44:05PM -0500, Richard Seaman, Jr. wrote: On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: FreeBSD's threads should perform adequately given the design of your program and the hardware you listed. Actually trying it on the various operating systems would be a good exercise, but I have found that FreeBSD's threads perform at least as well as Solaris's for such an application. Interesting. I would have thought Solaris would be much superior. LinuxThreads will definitely bog down with so many threads because the kernel scheduler has to deal with so many clone()d processes. Somewhat. But its nothing compared to the slowdown in the libc_r scheduler, in my experience. Each context switch (or each time the libc_r scheduler examines its state to consider a context switch), it executes a poll call to examine the state of *each* file descriptor that is considered "blocked" (of course its not really blocked in the kernel -- libc_r converts all i/o calls to non-blocking and polls their status to determined when i/o can be done). If you have hundreds/thousands of threads and each has an open file descriptor that has to be polled, linuxthreads is much faster, at least for the tests I've run. However, linuxthreads will consume a lot more kernel resources, so this only holds if you can tolerate the load on your resources. Interesting. Unfortunately, when I was developing the server I referred to, I was never able to get past about 100 connections on FreeBSD without crashing the kernel, because of the static buffer limits in the kernel (yes, I manually specified very large mbuf limits). As a result, I never experienced the scaling problems you mention. =) Linux runs into problems at less than 4000 threads because of a limit on the total number of processes, even if the thread stack size is decreased. I have run threaded tests on Solaris with over 30,000 connections without problems, other than kernel deadlock due to resource starvation when stuffing too many kernel-side socket buffers with data. FreeBSD's libc_r does not use clone() or anything similar. Instead, it is a userland call conversion library that multiplexes threads in a single process. This style of threads library should perform well for the type of application you are dealing with. Perhaps. The proposed "new" threads model that I understand you are working on should be *much* superior in this kind of application to either libc_r or linuxthreads, I would think. I hope so, because it's going to be a bit of work. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multithreaded server performance
On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote: I am currently porting a multithreaded TCP server from NT (yech!) to UNIX using pthreads. The server has a fairly straightforward design -- it opens a thread for each connection, and each thread spends most of its life blocked in a call to read() from a socket. As soon as it receives enough of a request, it does quite a bit of processing and sends something back to the client. This design isn't ideal on any OS, but the fact that you do significant processing every time a request arrives on a socket probably hides most of the inefficiency due to thread switching and lack of cache locality due to many thread stacks. How would FreeBSD 4.0 perform in such a scenario? We are talking hundreds, maybe thousands of threads, a lot of them doing blocking reads and writes. Is the standard pthreads library adequate for the task, or would "Linuxthreads" be a better choice? What is the main difference between the standard FreeBSD pthreads and "Linuxthreads" -- it seems both are implemented using a version of clone(). FreeBSD's threads should perform adequately given the design of your program and the hardware you listed. Actually trying it on the various operating systems would be a good exercise, but I have found that FreeBSD's threads perform at least as well as Solaris's for such an application. LinuxThreads will definitely bog down with so many threads because the kernel scheduler has to deal with so many clone()d processes. FreeBSD's libc_r does not use clone() or anything similar. Instead, it is a userland call conversion library that multiplexes threads in a single process. This style of threads library should perform well for the type of application you are dealing with. Note that there is also ports/devel/linuxthreads, which is based on rfork(), which can be made to behave like Linux's clone(). Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (forw) Re: readdir_r thread safe?
On Sat, Feb 05, 2000 at 03:16:28PM -0800, Alfred Perlstein wrote: Ugh, I should have brought this up before the code freeze but... Maybe we could make 4.0 the transition point for adding locking structures to FILE and DIR structures instead of the hackish way it's done now (maintaining a seperate structure). Does anyone agree or have time for this? It would greatly simplify the code and actually fix the readdir_r problem. Well, my personal opinion is that we shouldn't muck with this during the code freeze, but if there's agreement (and approval from Jordan) that it should happen before the 4.0 release, I'm willing to do the work. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
On Sun, Jan 23, 2000 at 11:36:08AM -0500, Mikhail Teterin wrote: David Schwartz once stated: = =FreeBSD: = == = If timeout is a non-nil pointer, it specifies a maximum = == = interval to wait for the selection to complete. = While the pthreads case is clearly a bug, in the other cases, =FreeBSD's behavior seems correct. The timeout is bounding the time we =wait for the selection to complete. However, the time to get back to =the task includes more than just the time spent waiting for the =selection to complete. I don't think this is "clearly a bug" in the pthreads case. It appears, that you, as well as other developers, speak from the implementation point of view. I only look at the man-page. The man page says, the time out is the UPPER limit. The pthread case is broken even further... Bruce, it appeared, tried to say the man-page is broken, while the implementation is correct, but remains silent despite me quoting all sorts of other man-pages from all sorts of other vendors, who all say (almost) the same thing: that the timeout is indeed the UPPER limit, and not the LOWER. I thought Bruce was pretty clear when he explained that such upper bounds are not possible unless the operating system can make hard real-time guarantees. FreeBSD is clearly not capable of hard real-time. If I remember correctly, neither are any of the operating systems from which you quoted man pages. That makes *all* of those man pages inaccurate. FreeBSD can put a process to sleep for a specified period of time, but it absolutely does not guarantee that the process will be run again precisely when the timeout has expired. In fact, as explained in earlier email, the timeout is rounded up in order to be certain that the process isn't woken up too early. Our man page is wrong: If timeout is a non-nil pointer, it specifies a maximum interval to wait for the selection to complete. This could perhaps be rewritten to say: If timeout is a non-nil pointer, it specifies a constrained lower bound on the maximum interval to wait for the selection to complete before again allowing the process to run. This reflects reality more closely, but I wouldn't argue for it being a better man page explanation of select() timeout semantics. If you can come up with some better wording that you can convince a committer is accurate and comprehensible, you might consider pursuing this issue. That's the only direction I have any interest in following this discussion in, however. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preemptiveness of FreeBSD threads
On Sun, Jan 16, 2000 at 10:18:56PM -0700, Wes Peters wrote: Michael Bacarella wrote: Program, when killed with SIGINT, prints all counters and exits. Now, as I understand, userspace threads in FreeBSD are preemptive. So, though my 11 threads are all computational and do not do any syscalls, sleeps, sched_yield, whatever -- newertheless, the program should not be stuck in one thread. And it seems to be sometimes true. But only sometimes! Hmmm, my prior response was pretty much bullshit. It doesn't work for me with 'volatile' at all. [...] Putting a sched_yield(); in the loop body makes sure that they get their fair share, so, other than guessing FreeBSD is at fault, I'm out of ideas. :) Yup, that does it, but it makes the program several orders of magnitude slower, too. Be careful about how much you use sched_yield, you're pushing the system into behavior that is outside its normal operating design. FreeBSD wasn't designed to re-run the scheduler after 2 or 3 instructions. In the case of libc_r, a call to sched_yield doesn't result in the system call sched_yield. Rather, it causes the userland threads scheduler to be run. There is still plenty of overhead, but running the kernel scheduler isn't necessarily part of that overhead. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: GTK threading on FreeBSD (and possibly other unices)
On Thu, Jan 13, 2000 at 10:27:23AM +0100, ROGIER MULHUIJZEN wrote: I'm forwarding this from the GTK development list. According to Owen their is something wrong with the threads implementation Is that true? or is it a "It's not the way Linux works, so it must be wrong"-pigheadedness? =) Chances are that there is a bug in the application in question. Buggy threaded programs behave differently, depending on the underlying threads implememtation, so the brokenness may not be apparent on another platform. The email exchange that you forwarded doesn't give too much insight into what the problem is (at least not that I picked up). However, the fact that the author thinks sleep(0) is a good idea for encouraging thread switching isn't a good sign (i.e. the author probably doesn't have a good grasp on threaded programming), and makes me further suspect that the application in question is buggy. Chances are good that the application has one or more threads in a buzz loop, which is causing the GUI thread to starve. On Linux, the fact that threads are scheduled by the kernel may nice down the buzzing threads and make the application appear to be working okay. This is all highly speculative. Take it for what it's worth. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile
On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: Consider as an example that open() is a thread cancellation point according to POSIX. If libpthread overrides the libc open() with its own version of open(), then by extension, every function that calls open() can potentially cause thread cancellation. This propagation of cancellation points is legal in a specified list of libc functions, but POSIX also says that *no* functions not in that list may act as cancellation points. That means that we have to be absolutely sure not to propagate cancellation points within libc, and short of constructing and analyzing a full call graph of the libc internals, this is the only way (that I can think of) to assure that libc doesn't incorrectly propagate cancellation points. Use _open internally within libc and libpthread. Have one "open" entry point that is the cancellation version of open. It isn't adequate to only have two names with a libpthread. There has to be: 1) _open() -- A name to access the actual system call. 2) _libc_open() -- A name that libc uses internally which by default is the same as _open(), but can be overridden. 3) open() -- The name that an application uses (and cancellation point). As mentioned in my previous email, if we were to remove _libc_open() and use open() instead inside of libc, we would incorrectly propagate cancellation points. If we were to remove _libc_open() and use _open() instead inside of libc, then we would have the problem of some libc functions using system calls directly, where libpthread needs to do call conversion and/or extra bookkeeping work. (I experienced this problem in tests first-hand while doing the conversion; hence the renaming of functions in libc_r.) We can argue about names, but I don't see any way to get around having three names. That said, I get momentarily confused about this every time I have to think about it, so if I'm really missing something, please help me to figure it out. =) How are you going to handle locking inside libc, if the locking functions are not inside libc? I dunno. =) Seriously, I haven't given much thought to this yet, and can't claim to understand all the issues involved. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile
[CCed to -hackers since this may be of general interest.] On Wed, Jan 12, 2000 at 11:21:41PM -0800, David O'Brien wrote: I'm still a little puzzled why every call to open got changed to _libc_open rather than do the magic w/in open(). Consider as an example that open() is a thread cancellation point according to POSIX. If libpthread overrides the libc open() with its own version of open(), then by extension, every function that calls open() can potentially cause thread cancellation. This propagation of cancellation points is legal in a specified list of libc functions, but POSIX also says that *no* functions not in that list may act as cancellation points. That means that we have to be absolutely sure not to propagate cancellation points within libc, and short of constructing and analyzing a full call graph of the libc internals, this is the only way (that I can think of) to assure that libc doesn't incorrectly propagate cancellation points. So, once we switch from libc_r to libpthread, we will have to implement, for example open() and _libc_open() in libpthread, where open() tests for cancellation, then calls into _libc_open(), which does the real work and presumably culminates in a call to _open(). In fact, we can probably make cancellation work correctly even in libc_r now, but I'll convert to libpthread first (the order these things are done in doesn't matter much). Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding alternate entry points to libc (was Re: Possible libc changes to support LinuxThreads)
On Tue, Jan 11, 2000 at 12:49:32PM -0600, Richard Seaman, Jr. wrote: On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote: The naming approach I'm taking is: fwrite() -- Alternate entry point that is used externally unless another library overrides it. _libc_fwrite() -- `_libc_' prefix. Alternate entry point for internal library use. __fwrite() -- `__' prefix. Actual name. The reason for a prefix of `__' instead of `_' in the actual name case is that using only one underscore would be ambiguous at least in the cases of setjmp()/_setjmp() and longjmp()/_longjmp(). FYI, the actual name with a single '_' is already defined for syscalls via SYS.h. Aliasing '__sycall' to '_syscall' is ok, I assume. Or, are you planning on replacing the '_syscall's? Setjmp/_setjmp are libc calls but not syscalls. I'm under the impression that linux glibc uses both single and double underscore symbols, but I don't recall exactly what distinction they make between the two. It would be more consistent to change to `__' for syscalls, but I was planning on leaving the syscalls with `_', and adding `__' aliases, for fear that changing it would violate some "law of libc". Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD.
On Tue, Jan 11, 2000 at 03:23:13PM -0800, Scott Hess wrote: Matthew Dillon [EMAIL PROTECTED] wrote: A better solution may be to shift to FreeBSD4.0 (when it's released - wait for it to become good and stable), and then use the native linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. After a number of hours hacking around with linuxthreads under 3.3-stable and 3.4-stable, I'm wondering if this suggestion was a joke of some sort that I just didn't get? As far as I can tell, the linuxthreads source code contains no files newer than mid December 1997. That would predate FreeBSD3.x entirely, wouldn't it? No wonder I'm having such an awful time getting things compiled. Please please please tell me that I'm REALLY missing something, here. Is there newer code hidden somewhere? The linuxthreads port switched to glibc-linuxthread-2.1.2 a couple of weeks ago. As mentioned by someone else (Alfred?), you *will* have problems with linuxthreads on -stable SMP, but it may work on -stable otherwise (I haven't tried it). It sounds like you need to do a cvsup. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AIO was Re: Kernel threads
On Mon, Jan 10, 2000 at 10:48:29PM +0100, Arjan de Vet wrote: Christopher Sedore wrote: On Thu, 6 Jan 2000, Arjan de Vet wrote: Jordan K. Hubbard wrote: This is very interesting data and I was just wondering about the actual state of functionality in our AIO code just the other day, oddly enough. Does anyone have a PR# for the mentioned patches? kern/12053 A Dec 16 version of the patch can be found at: http://tfeed.maxwell.syr.edu/aio-diff They won't apply cleanly because some new syscalls have been added. There may be another PR related too (although a quick search a few seconds ago didn't show it)--this patch set also fixes a problem where signals were not posted for aio completion under certain circumstances (the code just wasn't there before). Just found the PR--kern/13075 Now that we've found the two PRs and a reasonable up to date version of the patch are these changes going to be committed? Or are they still under review? Just curious ;-). I'm reviewing them right now. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
On Sun, Dec 19, 1999 at 03:01:41PM -0500, Chris Sedore wrote: On Sat, 18 Dec 1999, Alfred Perlstein wrote: On Sat, 18 Dec 1999, Kevin Day wrote: The _clean_ way of doing it would be to write your multi-user server using threads, and to assign one thread to each connection. If you can do that, then the logic in the program becomes quite simple. Each thread just sits there, blocked on a call to read(), until something comes in, and then it just parses the command, does whatever it is supposed to do in response to that command, and then goes back to the read() again. But as I understand it, there is not yet sufficient threads support in the FreeBSD kernel to make this work well/properly. (I may perhaps be misinformed about that, but that's what I have been told anyway.) I believe this is how ConferenceRoom works, so it seems ok, but I remember the comments that FreeBSD was their least preferred platform because of thread problems. Using a thread per connection has always been a bogus way of programming, it's easy, but it doesn't work very well. Ahem. Well, that kind of depends on the threads implementation, how many connections you're talking about, and likely some other factors too. I've got an NT box that handles about 1000 concurrent connections with 1000 (plus a few) threads doing the work. Runs fine, performs very well. I wouldn't argue that it is the most scalable solution to problems, but it is easier, and scales proportionally to the quality of the threads implementation. 1000 simultaneous connections really isn't that many, but even at 1000 threads, you could likely achieve much better performance by using thread pools or a simple poll() loop rather than one thread per connection. Why? Locality, locality, locality. Consider that each thread has its own stack, which in the best of worlds would be 4K, but is more likely at least 16K. Now, start switching between threads to handle relatively small amounts of I/O for each connection, and consider what that does to the VM, not to mention the memory hierarchy of the hardware. You might as well not even have L2 cache, because the program will thrash the cache so badly. Of course, you won't see worst case performance if client activity is unevenly distributed, but you just can't get past the fact that the memory footprint of one thread per connection is larger than a bounded pool of threads. Some threads implementations are better than others at handling such abuses, but the performance of such an approach will almost always suffer in comparison to a design that takes locality into consideration. I disagree with your assessment that scalability of one thread per connection is proportional to the quality of the threads implementation. An ideal threaded program would have exactly as many threads as available processors, and the threads would always be runnable. Of course, real-world applications almost never work that way, but the goal of a programmer should be to have as few threads as possible while still achieving maximal parallelism. If connection scalability is an issue, using one thread per connection ignores a critical aspect of high performance threaded application design. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
On Mon, Dec 20, 1999 at 08:24:28PM -0500, Chris Sedore wrote: On Mon, 20 Dec 1999, Jason Evans wrote: I disagree with your assessment that scalability of one thread per connection is proportional to the quality of the threads implementation. An ideal threaded program would have exactly as many threads as available processors, and the threads would always be runnable. Of course, real-world applications almost never work that way, but the goal of a programmer should be to have as few threads as possible while still achieving maximal parallelism. If connection scalability is an issue, using one thread per connection ignores a critical aspect of high performance threaded application design. I don't disagree with any of what you have written. I'd expect you to concede that it is true that the scalability is proportional. That is, LinuxThreads (that is, rfork()) is probably not anything like optimally scalable, but something like the last FreeBSD KSE model that I saw bouncing around on -arch would do alot better. Yes, LinuxThreads has a number of scalability problems that make using even a relatively small number of threads perform quite poorly, especially if there are multiple multi-threaded applications running on the same machine. I have serious issues with the 1:1 approach that LinuxThreads uses, because it fails to perform reasonably for anything but a very constrained set of multi-threaded programming models. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Possible libc changes to support LinuxThreads
I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2) running, but ran into a couple of minor problems integrating with our libc. LinuxThreads redefines a number of functions in order to make them either support thread cancellation or work correctly. The following functions need an alternative name, just as, for example, write() is actually _write(): lseek() pause() system() tcdrain() wait() waitpid() recv() send() This would allow implementing cancellation points for these functions. All in all, I won't lose much sleep over this, but if it's easy to do and doesn't violate some rule of symbol naming, it would be nice. The other issue has to do with longjmp() and siglongjmp(), and is of a similar nature, except that _longjmp() already exists as a separate interface. So, at least in the case of longjmp(), it needs to have a different alias, perhaps __longjmp(). Below is a *very* simplistic patch to libc that works, but it may make some people's skin crawl. Feedback is welcome. If there is no correct way to create aliases to function entry points, then we can do without them, but it will mean that the *jmp() functions cannot be used in conjunction with thread cleanup handlers when using LinuxThreads. Jason Index: i386/gen/setjmp.S === RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v retrieving revision 1.11 diff -u -r1.11 setjmp.S --- setjmp.S1999/10/10 08:38:33 1.11 +++ setjmp.S1999/12/09 02:07:45 @@ -54,6 +54,7 @@ #include "DEFS.h" #include "SYS.h" +ENTRY(__setjmp) ENTRY(setjmp) movl4(%esp),%ecx PIC_PROLOGUE @@ -80,6 +81,7 @@ xorl%eax,%eax ret +ENTRY(__longjmp) ENTRY(longjmp) movl4(%esp),%edx PIC_PROLOGUE Index: i386/gen/sigsetjmp.S === RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v retrieving revision 1.13 diff -u -r1.13 sigsetjmp.S --- sigsetjmp.S 1999/09/29 15:18:35 1.13 +++ sigsetjmp.S 1999/12/09 02:07:45 @@ -59,6 +59,7 @@ * use sigreturn() if sigreturn() works. */ +ENTRY(__sigsetjmp) ENTRY(sigsetjmp) movl8(%esp),%eax movl4(%esp),%ecx @@ -89,6 +90,7 @@ xorl%eax,%eax ret +ENTRY(__siglongjmp) ENTRY(siglongjmp) movl4(%esp),%edx cmpl$0,44(%edx) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible libc changes to support LinuxThreads
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: The problem with cancellation points, libc and linuxthreads has been that you need to wade through libc and replace instances of, for example, write() with either _write() or _libc_write() in order to avoid propagating cancellation points where they don't belong. Now I understand why you claimed that making cancellation work is a lot of work. Since that isn't currently done, do you think it would be better to leave broken cancellation in the LinuxThreads port, or to take it out? As things stand right now, "broken" means: 1) Not all mandatory cancellation points are implemented. 2) Some functions may act as cancellation points, even though they shouldn't. We can fix 1) with some symbol munging, but 2) is much more difficult, as you point out. The other issue has to do with longjmp() and siglongjmp(), and is of a similar nature, except that _longjmp() already exists as a separate interface. So, at least in the case of longjmp(), it needs to have a different alias, perhaps __longjmp(). Below is a *very* simplistic patch to libc that works, but it may make some people's skin crawl. Feedback is welcome. If there is no correct way to create aliases to function entry points, then we can do without them, but it will mean that the *jmp() functions cannot be used in conjunction with thread cleanup handlers when using LinuxThreads. __longjmp() and __siglongjmp() don't bother me at all. Following is a slightly better patch that uses weak aliases. longjmp() must be an alias for __longjmp() since _longjmp() is a public interface. However, siglongjmp() could be an alias for either _siglongjmp() or __siglongjmp(). Is _siglongjmp() more consistent? Of course, this doesn't matter at all if we leave out cancellation entirely. Index: i386/gen/setjmp.S === RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v retrieving revision 1.11 diff -u -r1.11 setjmp.S --- setjmp.S1999/10/10 08:38:33 1.11 +++ setjmp.S1999/12/09 20:53:11 @@ -54,7 +54,9 @@ #include "DEFS.h" #include "SYS.h" -ENTRY(setjmp) +ENTRY(__setjmp) +.weak setjmp; +.set setjmp, __setjmp; movl4(%esp),%ecx PIC_PROLOGUE leal28(%ecx), %eax @@ -80,7 +82,9 @@ xorl%eax,%eax ret -ENTRY(longjmp) +ENTRY(__longjmp) +.weak longjmp; +.set longjmp, __longjmp; movl4(%esp),%edx PIC_PROLOGUE pushl $0 /* (sigset_t*)oset */ Index: i386/gen/sigsetjmp.S === RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v retrieving revision 1.13 diff -u -r1.13 sigsetjmp.S --- sigsetjmp.S 1999/09/29 15:18:35 1.13 +++ sigsetjmp.S 1999/12/09 20:53:11 @@ -59,7 +59,9 @@ * use sigreturn() if sigreturn() works. */ -ENTRY(sigsetjmp) +ENTRY(__sigsetjmp) +.weak sigsetjmp; +.set sigsetjmp, __sigsetjmp; movl8(%esp),%eax movl4(%esp),%ecx movl%eax,44(%ecx) @@ -89,7 +91,9 @@ xorl%eax,%eax ret -ENTRY(siglongjmp) +ENTRY(__siglongjmp) +.weak siglongjmp; +.set siglongjmp, __siglongjmp; movl4(%esp),%edx cmpl$0,44(%edx) jz 2f To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
*jmp() renaming in libc
I'm porting the most recent released version of LinuxThreads (glibc-linuxthreads-2.1.2), and ran into a bit of a problem with regard to longjmp() and siglongjmp(). LinuxThreads wraps these functions so that they work correctly in the presence of cleanup handlers. However, this doesn't appear to be possible with our C library, since there are no other names by which to access sigsetjmp() and siglongjmp(). I noticed the following comment in src/lib/libc/i386/gen/sigsetjmp.S: /*- * TODO: * Rename sigsetjmp to __sigsetjmp and siglongjmp to __siglongjmp, * remove the other *jmp functions and define everything in terms * of the renamed functions. This requires compiler support for * the renamed functions (introduced in gcc-2.5.3; previous versions * only supported *jmp with 0 or 1 leading underscores). * [...] */ If this were done, I think it would solve my problem. However, it looks to be an almost trivially easy change for someone familiar with libc, yet it hasn't happened for the several years that it has been possible. Also, for the alpha platform, sigsetjmp() and siglongjmp() are defined in terms of setjmp(), _setjmp(), longjmp(), and _longjmp(), which is essentially the opposite approach of what the TODO comment suggests. Is there a reason that this TODO comment hasn't been acted on, other than no one getting around to it? Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
