On 10.12.2012 20:13, Linus Torvalds wrote:It's worth giving this as much testing as is at all possible, but at the same time I really don't think I can delay 3.7 any more without messing up the holiday season too much. So unless something obvious pops up, I will do the release tonight. So testing will be minimal - but it's not like we haven't gone back-and-forth on this several times already, and we revert to *mostly* the same old state as 3.6 anyway, so it should be fairly safe.
So, here's what I found. In short: close, but no cigar!Kswapd is certainly no more CPU pig, and memory seems to be utilized properly (the kernel still likes to keep 400MB free, somebody else can confirm if that's to be expected on a 4GB THP-enabled machine). So it looks very decent, and much better than anything I run in last 10 days, barring !THP kernel.
What remains a mystery is that kswapd occassionaly still likes to get stuck in a D state, only now it recovers faster than before (sometimes in a matter of seconds, but sometimes it takes a few minutes). Now, I admit it's a small, maybe even cosmetic issue. But, it could also be a warning sign of a bigger problem that will reveal itself on a more loaded machine.
I will now make one last attempt, I've just reverted 2 Johannes' commits that were also applied in attempt to fix breakage that removing gfp_no_kswapd introduced, namely ed23ec4 & c702418. For various reasons the results of this test will be available tommorow, so it's your call Linus.
To better document this whole mess from my point of view, I've attached two graphs. First one nicely shows kswapd frenzy a week ago (blue mountains on a CPU graph). On Thu 06 & Mon 10 (until few hours ago) I run !THP kernels, better memory utilization is, I think, obvious (look at the bottom graph, lots of green is evil). CPU spikes at the end of every day are daily backup runs, which are CPU, NOT I/O bound. Notice L.A. close to 1 on !THP kernels (as it should be), and almost 2 (Fri & Sat 08) when the backup fought with kswapd (and also big CPU iowait times in that case). Finally, todays run is somewhere in between, that's why it deserves "close, but no cigar" qualification. ;)
The last graph shows CPU usage in more detail, yesterdays run was on a !THP kernel, todays THP run is the one with red spikes. That was kswapd in D state, in congestion_wait().
-- Zlatko
Attachment:
screenshot1.png
Description: PNG image
Attachment:
screenshot2.png
Description: PNG image
