Oops, I just noticed this:
Ok, that answers my question. Here goes; hopefully this info will help:
I don't remember what situation no-op was created for, but I think it's for a specific type of kernel debugging or something equally specialized. Basically, if you don't already know that you need to use no-op, you should probably forget that it even exists.
That leaves us with the three real schedulers: deadline, anticipatory, and CFQ.
The deadline scheduler is, by far, the most similar to what kernel 2.4 uses. It's probably also the most mature. So, if you want stability above all, performance be damned, then I'd recommend using the deadline scheduler. However, I would only do that in situations where truly extreme paranoia is warranted (unless it's really a workload where deadline is the best scheduler, of course). In the real world, unless you have critical uptime requirements, I would pick the best scheduler and only use 2nd-best if the best choice takes the system down -- because for some workloads, using deadline instead of anticipatory or CFQ is almost as bad as taking the whole system down.
If you're running some kind of database workload, or other stuff that involves tons of random accesses, the conventional wisdom is that deadline is best. If any scheduler could possibly beat deadline for this workload, it's CFQ. Anticipatory is going to be comprehensively and completely inferior for this type of workload, in any case (well, unless it gets tremendously improved by the kernel developers, but I'm going to discuss the present since I can't foresee the future).
The other workload where anticipatory is highly inferior is on anything that does lots of swapping. If you MUST use anticipatory on such a box (e.g. a desktop that doesn't have enough RAM), then dedicate an entire hard drive just to the swap partition so that you can use a different scheduler (I guess CFQ would be the best choice, but I'm not certain, and deadline would also be good) on that drive alone. It's probably easier to just avoid anticipatory, or to add more RAM.
Anticipatory's performance penalty on swap partitions is huge -- in and of itself, it was sufficient grounds for Red Hat to decide that anticipatory simply could not be the default scheduler in their kernels.
However, anticipatory excels when the workload has an intermittent stream of writes competing against a large continuous stream of reads (or vice versa), such as web browsing while burning a DVD, or (especially) trying to do anything while a huge file is being written. In these kinds of workloads, anticipatory can increase performance by (in extreme cases) one or two orders of magnitude when compared to deadline. That, combined with the fact that CFQ didn't make it into kernel 2.6.0, is why anticipatory is the default scheduler for the mainline kernels.
On workloads with competing streams (i.e. what I described above), CFQ probably falls somewhere between deadline and anticipatory, although much closer to anticipatory, especially on more recent kernels. In fact, on very recent kernels, CFQ might even be able to beat anticipatory at its own game, but I don't know for sure one way or the other. In any case, CFQ doesn't have anticipatory's weaknesses (at least, not that I've seen). So, for general-purpose stuff (including typical desktops, and probably typical servers), CFQ is the best choice, and in fact, it's what Red Hat ships as the default choice in their kernels.
This post ended up being longer than I expected, so I'll try to summarize here:
Database servers: 1st choice is deadline, 2nd is CFQ, distant 3rd is anticipatory
Desktop/workstation with too little RAM: 1st choice is CFQ, distant 2nd is deadline, even more distant 3rd is anticipatory
Desktop/workstation with lots of RAM: 1st is CFQ, close 2nd is anticipatory, and deadline is a distant 3rd. If there's lots of CD/DVD burning simultaneous with other heavy activity, then anticipatory may be the leader however, especially if the kernel isn't bleeding-edge.
General purpose server with lots of sequential access to large files (e.g. file server with large files and a smal number of clients): 1st is CFQ, 2nd is anticipatory, somewhat distant 3rd is deadline
General purpose server with only small files, or where large files are always accessed randomly: 1st is CFQ, 2nd is deadline, 3rd is anticipatory
CFQ isn't quite a silver bullet scheduler, at least not yet, but it seems like it's slowly getting closer and closer as time goes on...
Perhaps other people will have different experiences and will disagree with me somewhat, but hopefully my advice is close to being on the mark. I hope this helps.