On Fri, May 2, 2008 at 1:27 PM, Chris Kuethe <[EMAIL PROTECTED]> wrote: > On Fri, May 2, 2008 at 12:11 PM, Maxim Belooussov <[EMAIL PROTECTED]> wrote: > > I have 2 computers, thinkpad T42 (i386) and sun ultra 10 (sparc64). > > Both are running current. I've tried to check in the kernel > > configuration files (GENERIC) where I can enable RTHREADS option, but > > couldn't find one. > > if it's not listed in GENERIC (even commented out) we don't really > think it's ready to use. At all. If you do feel like testing (and > maybe, just maybe, melting your entire system) ... it's not that hard > to copy the GENERIC config and add RTHREADS. it's just another > "option".
Or better, create a new config named RTHREADS that just contains these two lines: include "arch/i386/conf/GENERIC" option RTHREADS (Or include GENERIC.MP if this is a multiprocessor box.) > > The goal of my exercise is to check how much more responsive RTHREADS > > is vs PTHREADS scheduler on network level (i.e. shorter ping > > _response_ times, etc). > > not helpful at all. ping replies are handled in kernel. Right. rthreads only help threaded programs that block on disk-I/O or that have multiple CPU-bound threads. The latter are only helped if you really have multiple CPUs. Programs that are just network I/O bound will probably be *slower* with rthreads than with pthreads due to the increased overhead. > > I have tried to apply the patch to fresh source, only to see all 5 steps > fail. Wrong patch: the full one affects many more files than rthread_sync.c. If you're still interested in playing with rthreads despite the limited "only helps" list above and the fact that both firefox and openoffice are known to have issues with them, then I'll directly send you a gzipped copy of the patch. (Since the feedback on the patch has petered out, I suppose I should break it into logical chunks and send them to the tech list for piece-wise consideration.) Philip Guenther
