On Tue, Feb 04, 2014 at 03:14:24PM -0800, Andrew Morton wrote: > On Mon, 3 Feb 2014 19:53:32 -0500 Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > > o Fix vmstat build problems on UP (Fengguang Wu's build bot) > > > > o Clarify why optimistic radix_tree_node->private_list link checking > > is safe without holding the list_lru lock (Dave Chinner) > > > > o Assert locking balance when the list_lru isolator says it dropped > > the list lock (Dave Chinner) > > > > o Remove remnant of a manual reclaim counter in the shadow isolator, > > the list_lru-provided accounting is accurate now that we added > > LRU_REMOVED_RETRY (Dave Chinner) > > > > o Set an object limit for the shadow shrinker instead of messing with > > its seeks setting. The configured seeks define how pressure applied > > to pages translates to pressure on the object pool, in itself it is > > not enough to replace proper object valuation to classify expired > > and in-use objects. Shadow nodes contain up to 64 shadow entries > > from different/alternating zones that have their own atomic age > > counter, so determining if a node is overall expired is crazy > > expensive. Instead, use an object limit above which nodes are very > > likely to be expired. > > > > o __pagevec_lookup and __find_get_pages kerneldoc fixes (Minchan Kim) > > > > o radix_tree_node->count accessors for pages and shadows (Minchan Kim) > > > > o Rebase to v3.14-rc1 and add review tags > > An earlier version caused a 24-byte inode bloatage. That appears to > have been reduced to 8 bytes, yes? What was done there? Instead of inodes, the shrinker now directly tracks radix tree nodes that contain only shadow entries. So the 16 bytes for the list_head are now in struct radix_tree_node, but due to different slab packing it didn't increase memory consumption. > > 69 files changed, 1438 insertions(+), 462 deletions(-) > > omigod Most of it is comments and Minchan's accessor functions. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
