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 --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Michael Opdenacker | [PATCH] x86: fix unconditional arch/x86/kernel/pcspeaker.c compiling |
git: | |
| David Miller | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
