On Tue, 25 Nov 2014 21:40:07 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Tue, Nov 25, 2014 at 07:38:18PM -0500, Jeff Layton wrote: > > On Tue, 25 Nov 2014 19:09:41 -0500 > > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > I understand that's a lot of > > > information.) But it's nice to see some numbers at least. > > > > > > (I wonder what the reason is for the odd shape in the 112-thread case > > > (descending slightly as the writes decrease and then shooting up when > > > they go to zero.) OK, I guess that's what you get if you just assume > > > read-write contention is expensive and one write is slightly more > > > expensive than one read. But then why doesn't it behave the same way in > > > the 56-thread case?) > > > > > > > Yeah, I wondered about that too. > > I was also forgetting that these are percentage increases. > > For the future something that gave just the before and after numbers > side-by-side might be easier to think about? > Alas, that's what I can't release here. One of the perils of working at a secretive startup. The part I can talk about is the fio job he was using to test it: "It was a fio 70/30 r/w random mix, where every thread was on a separate file." ...and this about the server hardware: "On the server side it was Dual 2.6GHz Ivy-bridge 8-core w/ hyper threading enabled w/ 128GB RAM" Unfortunately, I can't tell much about the underlying storage on the server, other than that it's quite fast. > > There is some virtualization in use on the clients here (and it's > > vmware too), so I have to wonder if there's some variance in the > > numbers due to weirdo virt behaviors or something. > > > > The good news is that the overall trend pretty clearly shows a > > performance increase. > > Yep, sure. > > > > > As always, benchmark results point out the need for more benchmarks. > > > > -- > > Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
