Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+4\/4\]\s+xfs\:\s+convert\s+buffer\s+cache\s+hash\s+to\s+rbtree\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+4\/4\]\s+xfs\:\s+convert\s+buffer\s+cache\s+hash\s+to\s+rbtree\s*$/: 6 ]

Total 6 documents matching your query.

1. [PATCH 4/4] xfs: convert buffer cache hash to rbtree (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 9 Sep 2010 01:12:58 +1000; The buffer cache hash is starting to show typical hash scalability problems. large scale testing is showing the number of cached items growing far larger than the hash can efficiently handle. Hence w; /archives/xfs/2010-09/msg00120.html (23,210 bytes)
2. Re: [PATCH 4/4] xfs: convert buffer cache hash to rbtree (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Wed, 8 Sep 2010 21:51:50 -0400; Once thing that worries me about the rbtrees is that the Linux implementation doesn't allow for lockless readers. But in the end the buffer cache implementation is very well encapsulated, so if the n; /archives/xfs/2010-09/msg00135.html (10,526 bytes)
3. Re: [PATCH 4/4] xfs: convert buffer cache hash to rbtree (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 10 Sep 2010 13:22:00 +1000; Agreed. I'm going for simplicity of implementation first - list to rbtree conversion is pretty trivial and realtively easy to verify. We can revisit the choice of rbtrees later on if/when we need to.; /archives/xfs/2010-09/msg00165.html (11,841 bytes)
4. Re: [PATCH 4/4] xfs: convert buffer cache hash to rbtree (score: 1): Author: Alex Elder <aelder@xxxxxxx>; Date: Mon, 13 Sep 2010 11:53:49 -0500; I found a bug in this, and have a bunch of other less important comments for you to consider. I haven't spent any time contemplating your decision to use RB trees on AG's but it seems quite reasonabl; /archives/xfs/2010-09/msg00203.html (24,292 bytes)
5. Re: [PATCH 4/4] xfs: convert buffer cache hash to rbtree (score: 1): Author: Alex Elder <aelder@xxxxxxx>; Date: Mon, 13 Sep 2010 11:59:45 -0500; I'm pretty sure this is due to each buffer now holding a perag reference. It might be nice to preserve this functionality by checking against the number of blocks in the AG or something similar. But; /archives/xfs/2010-09/msg00204.html (9,900 bytes)
6. Re: [PATCH 4/4] xfs: convert buffer cache hash to rbtree (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 14 Sep 2010 17:13:58 +1000; That doesn't work. When we walk off the end of the tree, *rbp == NULL, but we need parent to point to the previous node we searched, as that is where we will insert the new node. The above code would; /archives/xfs/2010-09/msg00212.html (25,126 bytes)

Current List: 1 - 6
Page: [1]