On Tue, Dec 03, 2013 at 01:21:12PM -0500, Jeff Layton wrote: > Most of this code is protected by a single spinlock (cache_lock). The > main benefit to switching to list_lru would be that we could move to a > per-node lock. But, to make that worthwhile would mean we'd need to > redesign the locking and break the cache_lock into multiple locks. No need to redo locks just yet, the biggest benefit is to use a well debug library for lru list handling, with the second biggest one being that you get out of the box shrinker support. > Also, the existing code does take pains to reuse an expired entry off > the LRU list in preference to allocating a new one. The list_lru code > doesn't have a mechanism to scrape the first entry off the LRU list, > though I suppose we could add one or abuse the cb_arg in the walk > callback as a return pointer. That's just because it is an old-school cache with a fixed upper bound of entries and no shrinker support. With proper shrinker integration this nasty code isn't needed. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
