On Tue, Jul 03, 2012 at 02:31:19PM +0200, Daniel Vetter wrote: > On Tue, Jul 03, 2012 at 11:59:51AM +0100, Mel Gorman wrote: > > On Tue, Jul 03, 2012 at 10:19:28AM +1000, Dave Chinner wrote: > > > On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote: > > > > Adding dri-devel and a few others because an i915 patch contributed to > > > > the regression. > > > > > > > > On Mon, Jul 02, 2012 at 03:32:15PM +0100, Mel Gorman wrote: > > > > > On Mon, Jul 02, 2012 at 02:32:26AM -0400, Christoph Hellwig wrote: > > > > > > > It increases the CPU overhead (dirty_inode can be called up to 4 > > > > > > > times per write(2) call, IIRC), so with limited numbers of > > > > > > > threads/limited CPU power it will result in lower performance. Where > > > > > > > you have lots of CPU power, there will be little difference in > > > > > > > performance... > > > > > > > > > > > > When I checked it it could only be called twice, and we'd already > > > > > > optimize away the second call. I'd defintively like to track down where > > > > > > the performance changes happend, at least to a major version but even > > > > > > better to a -rc or git commit. > > > > > > > > > > > > > > > > By all means feel free to run the test yourself and run the bisection :) > > > > > > > > > > It's rare but on this occasion the test machine is idle so I started an > > > > > automated git bisection. As you know the milage with an automated bisect > > > > > varies so it may or may not find the right commit. Test machine is sandy so > > > > > http://www.csn.ul.ie/~mel/postings/mmtests-20120424/global-dhp__io-metadata-xfs/sandy/comparison.html > > > > > is the report of interest. The script is doing a full search between v3.3 and > > > > > v3.4 for a point where average files/sec for fsmark-single drops below 25000. > > > > > I did not limit the search to fs/xfs on the off-chance that it is an > > > > > apparently unrelated patch that caused the problem. > > > > > > > > > > > > > It was obvious very quickly that there were two distinct regression so I > > > > ran two bisections. One led to a XFS and the other led to an i915 patch > > > > that enables RC6 to reduce power usage. > > > > > > > > [aa464191: drm/i915: enable plain RC6 on Sandy Bridge by default] > > > > > > Doesn't seem to be the major cause of the regression. By itself, it > > > has impact, but the majority comes from the XFS change... > > > > > > > The fact it has an impact at all is weird but lets see what the DRI > > folks think about it. > > Well, presuming I understand things correctly the cpu die only goes into > the lowest sleep state (which iirc switches off l3 caches and > interconnects) when both the cpu and gpu are in the lowest sleep state. I made a mistake in my previous mail. gdm and X were were *not* running. Once the screen blanked I would guess the GPU is in a low sleep state the majority of the time. > rc6 is that deep-sleep state for the gpu, so without that enabled your > system won't go into these deep-sleep states. > > I guess the slight changes in wakeup latency, power consumption (cuts > about 10W on an idle desktop snb with resulting big effect on what turbo > boost can sustain for short amounts of time) and all the follow-on effects > are good enough to massively change timing-critical things. > Maybe. How aggressively is the lowest sleep state entered and how long does it take to exit? > So this having an effect isn't too weird. > > Obviously, if you also have X running while doing these tests there's the > chance that the gpu dies because of an issue when waking up from rc6 > (we've known a few of these), but if no drm client is up, that shouldn't > be possible. So please retest without X running if that hasn't been done > already. > Again, sorry for the confusion but the posted results are without X running. -- Mel Gorman SUSE Labs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
