On Fri, Aug 15, 2008 at 08:46:01AM -0400, Chris Mason wrote:Thanks, I figured it out. There were two reasons why I wanted to play with compilebench. The first is we have a fragmentation problem with delayed allocation and small files getting forced out due to memory pressure, that we've been working for the past week. My intuition (which has proven to be correct) is that compilebench is a great tool to show it off. It may not matter so much for write throughput results, since usually the separation distance between the first block and the rest of the file is small, and the write elevator takes care of it, but in the long run this kind of allocation pattern is no good: Inode 221280: (0):887097, (1):882497 Inode 221282: (0):887098, (1-2):882498-882499 Inode 221284: (0):887099, (1):882500 The other reason why I was interested in playing with compilebench tool is that I wanted to try tweaking the commit timers to see if this would make a difference to the result. Not for this benchmark, it appears, given a quick test that I did last night. - Ted --
| Michal Piotrowski | Re: Linux 2.6.21-rc4 |
| Satyam Sharma | [PATCH 0/8] i386: bitops: Cleanup, sanitize, optimize |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| David Woodhouse | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Alexey Dobriyan | Re: [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
