Messages in this thread | | | Date | Thu, 9 Feb 2012 09:59:48 -0800 | From | Tejun Heo <> | Subject | Re: [PATCH] block: strip out locking optimization in put_io_context() |
| |
Hello,
On Thu, Feb 09, 2012 at 02:22:32PM +0800, Shaohua Li wrote: > >> Tried all the options, the regression still exists. Any new idea? > >> I'll spend some time on it if I can get anything > > > > Can you please try the following one? Thanks a lot! > doesn't work. > I also double confirmed b2efa05265d62 causes the regression
I'll soon send a RCU based version. I'm still having trouble reproducing the regression tho. I've tried a few different things.
* Heavy thrashing: Disk IO dominates everything and CPUs aren't too busy. While how swap behaves affects completion time, I don't see how CPU locking issue comes into play at all under this circumstance.
* Some swap load: Simulated w/ 1G memory limit and buliding defconfig kernel in tmpfs. Swap grows to a couple hundred megabytes but build time is still dominated by CPU. I didn't see any meanginful difference before and after the commit - both in terms of wallclock and CPU times.
Maybe these two were too extreme to show the problem and I need to push memory limit a bit further, but it would be great if you can give me a bit more details about your testing.
* How much memory does the machine have? How is the tmpfs setup and filled up? What's the size of the tmpfs and the output of "free -m" right before test starts? While the test is running, how occupied are the CPUs? On test completion, what's the output of "free -m"?
* What exactly is the test and what do you measure? What does "12% regression" mean? Is it wallclock time or CPU time? If it's CPU time, does systime increase dominate the regression?
Thanks.
-- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |