Re: [PATCH] block: strip out locking optimization input_io_context()

[Tejun Heo]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/