Excerpts from Arne Jansen's message of 2011-07-27 04:13:44 -0400: > On 27.07.2011 00:00, Chris Mason wrote: > > Excerpts from Chris Mason's message of 2011-07-25 21:28:30 -0400: > >> Excerpts from Chris Mason's message of 2011-07-25 14:34:49 -0400: > >>> Hi everyone, > >>> > >>> I've updated the integration-test branch to use this code instead. It > >>> is a shiny new reader/writer lock built around rw spinlocks. I've > >>> removed all the adaptive spinning and started trusting the hints btrfs > >>> already has about when blocks should block or spin. > >> > >> I tested with lockdep and looks like I've got a bug in btrfs_next_leaf's > >> lockdep handling. So, please don't run this code with > >> CONFIG_DEBUG_LOCK_ALLOC turned on. The bug is only in lockdep mode, so > >> we're fine with it off. > >> > >> I'll fix it up in the morning. > > > > Ok, I've rebased the btrfs integration-test branch to include fixes for > > the lockdep problems. I've also adapted Tejun's lockdep class patch to > > the new code. With this setup I'm not getting lockdep warnings, but I'm > > always looking for more bug reports. > > > > My fs_mark test look strange. As I can't make sense of it and don't have > much time today to investigate, I just paste them here: > > fs_mark with b249e55006c87f (pre-r/w-lock): > FSUse% Count Size Files/sec App Overhead > 16 65536 51200 9603.3 2064173 > 27 131072 51200 7995.1 1710337 > 37 196608 51200 8662.7 2046263 > 47 262144 51200 8024.2 1876913 > 58 327680 51200 7564.5 1593306 > > # btrfs fi df /mnt/fsm > Data: total=4.21GB, used=3.70GB > System: total=4.00MB, used=4.00KB > Metadata: total=520.00MB, used=65.24MB > > fs_mark with integration-test: > FSUse% Count Size Files/sec App Overhead > 18 65536 51200 7617.4 882409 > 34 131072 51200 6447.1 935868 > 51 196608 51200 5697.7 938026 > 63 262144 51200 7462.9 933696 > 76 327680 51200 6807.7 921403 > > # btrfs fi df /mnt/fsm > Data: total=5.61GB, used=4.98GB > System: total=4.00MB, used=4.00KB > Metadata: total=520.00MB, used=77.04MB > > Please note the different fs usage after a single fs_mark run with > the same parameters (fs_mark -d /mnt/fsm -D 512 -t 16 -n 4096 > -s 51200 -L5 -S0). > Maybe fs_mark just have some problems with accounting when running > in multiple threads. Hmmm, I've always had fs_mark give me the same output (fsuse % numbers) for each run. I'd say you had a file in the FS at the start of the run. It looks like you're not CPU bound. We've got a few different tweaks in the integration-test branch right now, one of them must be flushing more often. You're also filling up the FS pretty quickly, so these results are probably bound by writeback. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
