Date: Fri, 16 Jul 1999 17:25:54 -0700 (PDT) From: Tani Hosokawa <unknown@riverstyx.net> To: Terry Lambert <tlambert@primenet.com> Cc: davids@webmaster.com, chat@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <Pine.LNX.4.10.9907161706170.23952-100000@avarice.riverstyx.net> In-Reply-To: <199907162345.QAA18013@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Jul 1999, Terry Lambert wrote: > > This isn't a discussion about Apache; Apache is just an example of piece > > of software that requires threads. Your argument was that making > > FreeBSD's threads efficient was a waste of time because nobody needs > > threads. My argument is that "needing" threads is irrelevant, because > > people use threads. > No, my argument was against getting al het up about FreeBSD not > having kernel threads, or all excited that kernel threads are > somehow important for performance. Threads are important for performance if the software you need to run uses threads. I'm repeating myself, but I have no choice. > > I just thought of another high profile system that uses threads. MySQL. > > It's all threaded. Threads for MySQL are damn cool, 'coz it leaves a tiny > > memory footprint, especially when compared to other similar systems like > > PostGres that are process oriented. > Yes. And you'll notice that it runs just fine on FreeBSD. So I guess > FreeBSD does have working threads. Does it? Would it work just as well if I had to have 3000 MySQL connections to a quad-Xeon running FreeBSD? > > Or, the aio_* functions that have been bandied around a bit. AFAIK, those > > are all implemented in their respective OS with kernel threads, are they > > not? > No. They are not. They are implemented with context structures, > which the kernel updates when the operation is completed as a > result of a wakeup() call -- in other words, the operation still > blocks the call, but it does not block the process that made the > call. See the man pages for aio_wait and aio_cancel for details of > the operation of the context structure. Ok, I'd heard they used threads. It's just one example. > > Zeus uses select, and has the problem that it blocks on I/O. It's not > > using the model you suggest. > Wait. Does it use "select", or does it "block on I/O". Select > does not return a 1 bit unless I/O will not block. It selects on network I/O. Filesystems accesses will still block, AFAIK. > > I've heard this can be a serious issue on, say, serving files off NFS. > > Doubly so on FreeBSD, I suppose... > Wrong. > fcntl( fd, F_SETFL, O_NONBLOCK); > It will return an "EWOULDBLOCK" on a failed attempt to read or write, > which could be reattempted later. A good way to burn CPU cycles. It's actually *more* efficient to have a thread blocking on I/O than it is to continually be trying reads, especially if you have multiple data sources, where only one of them is in a situation where it would block. > > > That's actually "what's wrong with applications?". The closest you > > > can get to blaiming FreeBSD for this is "why can't FreeBSD run > > > these applications that rely on threads in an SMP scalable way?". I > > > could easily ask a similar question: "why can't FreeBSD run Microsoft > > > Office 2000?". > > No, it's "what's wrong with FreeBSD?". > Funny; mySQL, ACAP, and LDAP are all threaded, and they all run fine > on FreeBSD. I can't comment on ACAP and LDAP, but I think you're entirely wrong about MySQL, at least in some circumstances. > So does nay other pthreads application that conforms to POSIX 1003.1c. > > Any application which doesn't run (e.g. the claims of one thread > blocking all other threads) is, by definition of POSIX 1003.1c, broken. That's a wacky claim. It's not a question of "running", it's a question of "running well" which is entirely different. > > So, go talk to the Apache Group and tell them your opinions. A lot of > > them have pretty strong opinions about this. > > > > This isn't an Apache issue. This is a simple question relating to one > > aspect of FreeBSD, and whether or not you agree with that aspect has no > > relevance. > Apache will run on FreeBSD. THe Apache group uses FreeBSD to serve > their web pages. They're not going to break that. I never suggested that Apache would break. I said that Apache wouldn't run as well under FreeBSD as it would under some OS that put a lot of effort into having more thread-friendly library routines, etc. This won't be an issue for Apache's homepage, but it will be an issue for Joe Blow with his big SMP box moving 50 megabit of data. In a case like this, it might even be cheaper to go with a different OS because you can skip buying an extra server. I don't know what the performance ramifications, but if FreeBSD isn't as fast as X OS, then you know what's going to get used... > > So? My point is, was, and will be, that FreeBSD doesn't *currently* have > > good threading. I never said that FreeBSD can't *get* good threading. > > FreeBSD currently has good threading. > > FreeBSD currently does not have SMP scalable threading. Neither does > Linux, given their lack of scheduler activations and CPU affinity code. Why do people always start off with that? Who cares? I don't care if Linux *specifically* has better threads than FreeBSD. I care that FreeBSD doesn't have the best threads. > Note that all these scheduler problems "just go away", if you are not > so stupid as to implement your threads as kernel objects (Like Linux > and Solaris and SVR4). > > It's not that "FreeBSD can't do blah blah blah", it's that "there has > been no compelling reason, so far, for FreeBSD to do blah blah blah" > (for the purposes of this discussion, "SMP scalable threads" is > "blah blah blah"). > > SMP scalability for user space threading in FreeBSD is a matter of > > 1) a small user space threads scheduler change to allow for > one stack per each anticipated CPU in user space. > > 2) the addition of one u_init32_t to the proc structure. > > 3) a straight forward addition of per CPU ready-to-run queues > and simple reference to the u_init32_t proc structure > element in schedcpu() that defaults to "0" (all bits not > set). Processes without the 0'th bit set would pick a > CPU based on which CPU has the lowest number of processess > in its ready to run queue. > > 4) a system call to allow more than one CPU to be asked to > visit user space (probably via a minor mod to rfork(2) to > add RFADDONECPU and RFADDALLCPU flags) that sets bits in > the u_init32_t, examines the global containing the number > of CPU's in the system, and adds an entry to the per CPU > ready-to-run queue of one (or more, if desired) CPU. > > 5) a minor change to execve(), exit1(), and fork1() to manage > the u_init32_t contents on a fork1() or execve() entry, > and to deschedule from other CPU's any scheduled entries > into user space on an execve() or exit1(). > > In other words, childs play. > > Now that I've listed it out, it would take a day, tops, for most > programmers I have ever worked with to implement. Even the > Microsoft Windows hacks, if I point them at the right files and > tell them where to type "make". Spiffy. Go for it. Or don't. The point is, that's not done, and even if what you say is correct, that's not done (did I say that already?). [semi-related stuff snipped] > > Server = runs server software, which means it is probably going to be > > doing one of a few tasks, mostly related to returning files or data. If > > it can't do that, then it's a bad server OS. And if a large number of > > software products require threads (and they do! they do! that's the > > point!) and FreeBSD can't do threads well, then it's a bad server OS. > > > > Ok, not necessarily bad -- just not suited to those particular tasks. > Server class software is generally software which is very aware of > performance issues. > > Software which is very aware of issues doesn't use threads (or at > least doesn't use threads in version 2.0). Non-blocking I/O, or > async I/O, if they are data pumps and need to interleave I/O instead > of increasing CPU cycles thrown at the problem -- not likely, given > that a single Xeon, the WC CDROM FTP server, can saturate an OC3, > and tops out on I/O capability, not instructions -- is a better > use of the CPU, than spending time in a user space (or kernel, if > the threads are badly implemented) scheduler. This is naive. The real world doesn't work this way. > > > Even given the existance of the evil "configure" program I really > > > doubt the Apache people aren't (very) wise to this. > > > > Yes, they are. That's the point of the APR and MPM projects. However, > > threading's in there! > > Uh, you are misreading this... read it again: > > > > Even given the existance of the evil "configure" program I really > > > doubt the Apache people aren't (very) wise to this. > ***** ****** > > It's a double negative indicating that I believe they are aware, > despite using "configure", of how to program server class software. I'm not misreading, I'm agreeing. I too believe that the Apache Group is a capable group of programmers. You were making some point about abstracting the scheduling, etc, which is what the APR and MPM projects are doing (as well as abstracting a bunch more stuff, but that's unimportant). My point was, yeah... but threading is in there, so get used to it and quit trying to avoid the actual issues. The issues are not the technical merits of programs that use threads. The issues are the ability of FreeBSD to provide an operating environment that is as or more efficient than that of other OS performing the exact same tasks with the exact same software (optimized for platform obviously, but I think it's a bit too much to ask for the entire software paradigm to be different on each OS). --- tani hosokawa river styx internet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.9907161706170.23952-100000>