Re: test11-pre6

Linus, You forgot about wakeup_bdflush(1) stuff. Here is the patch again (against test10). === There are several places where schedule() is called after wakeup_bdflush(1) is called. This is completely unnecessary, since wakeup_bdflush(

[patch] nfsd optimizations for test10 (yet another try)

Neil, Here is a set of fixes and answers to you questions/points. The new patch was tested in my own environment again and worked fine. 1/ Why did you change nfsd_busy into an atomic_t? It is only ever used or updated inside the Big-Kernel-Lock, so it doesn't need to be atomic. I think

[patch] nfsd optimizations for test10 (recoded to use list_head)

Hi, This is the recoded racache that uses list_head for several lists, e.g., lru and free lists. I have tested it under SPEC SFS runs, and several other NFS loads myself. Here is the whole patch against test10. = diff -ruN nfsd.orig/nfsd.h nfs

Re: [patch] nfsd optimizations for test10

1/ Do you have any stats showing what sort of speedup this gives - I'm curious. I don't have the exact timing stats to show the improvements, but I do have some stats that I gathered when running SPEC SFS. Basically with the default racache scheme which only keeps 80 entries in the table

problems with sync_all_inode() in prune_icache() and kupdate()

Hi, I'm wondering if someone can tell me why sync_all_inodes() is called in prune_icache(). sync_all_inodes() can cause problems in some situations when memory is short and shrink_icache_memory() is called. For instance, when the system is really short of memory, do_try_to_free_pages() is invoked

[patch] wakeup_bdflush related fixes and nfsd optimizations for test10

Hi, This patch includes two sets of things against test10: First, there are several places where schedule() is called after wakeup_bdflush(1) is called. This is completely unnecessary, since wakeup_bdflush(1) already gave up the control, and when the control is returned to the calling thread who

[patch] nfsd optimizations for test10

Hi, I made some optimizations on racache in nfsd in test10. The idea is to replace with existing fixed length table for readahead cache in NFSD with a hash table. The old racache is essentially ineffective in dealing with large # of files, and yet eats CPU cycles in scanning the table (even thoug

Re: VM in v2.4.0test9

I'd second that this is most likely a VM related problem. Last few days I sent you an example that I would make system hang simply by doing a mkfs on 90 GB file system. This happens when low 1GB memory is used up (but I still have high 1GB available). I think David probably ran into the same prob