On 11/30/2017 09:13 AM, Jens Axboe wrote: > On 11/29/2017 09:21 PM, Jens Axboe wrote: >> On 11/28/2017 09:13 PM, Elliott, Robert (Persistent Memory) wrote: >>> small_content_scramble has hardly been touched since 2011, so it probably >>> hasn't had much performance analysis. >> >> That's fair, would be a good thing to look at, especially since it's on >> by default. > > Something like this might be an improvement. The main change here is > that for each 512b chunk in the io_u buffer, we generate a "random" > index between 0..7 and scramble the start and end of that with the > offset and time. The difference here is that we do it all within a 64b > range within each chunk, which should fall into the same cacheline since > the io_u buffer is generally aligned. This cuts down on the number of > cachelines we dirty for each io_u, from a max of 16 to 8. > > We could further reduce this to 7, if we generate an overlapping > cacheline between chunks. That would place the data in the same spot > everytime, which isn't ideal though. > > I ran a quick null benchmark with this, and on my laptop it brings us > from 4061k/4068k to 4090k/4091k. Those are results from two runs, so not > very conclusive or definitive... Suggestions and tests would be welcome. > FWIW, this is what I ran: > > ./fio --name=null --size=100g --rw=write --ioengine=null --gtod_reduce=1 --scramble_buffers=1 --iodepth=64 --direct=1 --cpus_allowed=2 Ran the same thing on a server box, which generated very reliable results. It takes us from 3200K to 3340K. I'm going to commit this, but don't let that stop anyone from testing it and making suggestions on how we can further improve it. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
