There are also other concerns than the context switch overhead...particularly when dealing with filesystems or data storage devices.

For instance, suppose part of your userspace daemon gets swapped out, and you now need to upcall to userspace. That part that got paged out then has to be paged back in. If memory is tight, then the kernel may have to free some memory, and it may decide to flush out dirty data to the filesystem or device that is dependent on the userspace daemon. At that point, you're effectively deadlocked.

Most of those sorts of problems can be overcome with careful coding and making sure the important parts of the daemon are mlocked, but you do have to be careful and it's not always straightforward to do that.

I assume you're talking about client-side performance? If so, then yes it should be much better in RHEL6.

FWIW, The NFS tools don't really do much once you've got the filesystem mounted. (Ok, that's not 100% true with NFSv4 or Kerberized NFS but it is for the most part). Performance problems like this are generally in the kernel. I've got a patchset queued up to try and improve NFS write performance in RHEL5, but it probably won't go in until 5.7.

See this page if you want to test out what I have queued up so far. It's still pretty rough, but the results so far are quite promising:

        http://people.redhat.com/jlayton/

If you have a support contract, you should open a support case on this. Typically, performance problems are all about numbers so if you can quantify the problems you're seeing then we should be able to help.

...that can survive being turned into a MMORPG. Most developers tend to think that making a game into a MMOG adds value, but I tend to think it's the reverse.