Date: Tue, 15 Dec 1998 09:32:51 -0700 (MST) From: Kevin Van Maren <vanmaren@fast.cs.utah.edu> To: smp@FreeBSD.ORG Subject: Re: Pthreads and SMP Message-ID: <199812151632.JAA26636@fast.cs.utah.edu>
next in thread | raw e-mail | index | archive | help
Sometimes I have to remember to take what Terry says with a grain of salt. Modern small-scale SMPS (2 or 4-way) have very fast and efficient communication. Yes, the less communication between threads the faster they will run. Yes, CPU-inheritance scheduling can make a big difference, especially with large per-cpu caches. Yes, NT doesn't scale very well on the 4 and 8-way hardware because of it's synchronization mechanisms. That aside, it is most certainly desirable to be able to run multiple threads in parallel. The extent to which user threads are mapped onto processors is best controlled by some provided mechanism (such as pthread_setconcurrency and pthread_getconcurrency) rather than an inflexible policy such as "I believe it may be slow to run multiple threads at the same time". As for Terry's beef about the page table, I don't know how often a typical app gets its page table updated, but I wouldn't think that would be common except when a) you are paging and other performance penalties are likely to be in the noise or b) more memory is being allocated/accessed by the process. It is only necessary to do a TLB-shootdown when restricting the mappings. It isn't a problems if a processor takes a trap because its TLB was out of date and the page is really valid; it simply loads the new info and continues. I believe we should add the necessary mechanisms to run threads in parallel and THEN look at the actual performance problems and address them. If that means the scheduler needs to be improved, fine, we improve the scheduler. If some applications run slower on multiple processors, we just have them call pthread_setconcurrency(1). Shoot, Terry can make the default to be 1 on his machines. Personally, I would like to be able to use pthread_create() instead of fork() to handle computation- bound requests. Terry has a point about wanting to design the system to be fast from the beginning. That is almost certainly better than to design something, realize it is way to slow, and then hack on it forever. However, having this working in the short term and rewriting it for the long term doesn't upset me too much -- I just want it working, and it will certainly be good enough for a large range of applications (even it it isn't large enough or good enough for Terry). Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812151632.JAA26636>