Messages in this thread |  | | Date | Mon, 13 Oct 2003 04:54:58 -0700 | | From | William Lee Irwin III <> | | Subject | Re: [PATCH] Invalidate_inodes can be very slow |
| |
William Lee Irwin III <wli@holomorphy.com> wrote: >> Generally dcache_lock stands in front of inode_lock, even with the >> current hashtable RCU code. inode_lock has been seen before in unusual >> situations I don't remember offhand, though generally it's not #1. >> The workloads used for, say, benchmark testing don't adequately model >> situations like what you just mentioned (or a number of other real-life >> usage cases), so per-sb inode_lock may be worth considering on a priori >> grounds, though it would probably be better to actually set something >> up to test that scenario.
On Mon, Oct 13, 2003 at 03:45:01PM +0400, Kirill Korotaev wrote: > This patch can be tested quite easily. Main changes are in invalidate_list. > This path can be triggered by umount/quota off. > So I tested it the following way: > 1. mounting/working/umounting partition (and turning quota on/off) > 2. running memeater to call prune_icache when partition was mounted > to test that lists are ok. > All other places should be ok, since simple list_add/list_del is inserted.
Sorry if I was unclear, I had in mind SMP performance testing of mount and unmount -heavy workloads, like uni setups with many automounted fs's, not stability testing per se.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |