KernelTrap - vm

Linux: 2.6.34-rc4, "Hunting A Really Annoying VM Regression"

Jeremy — Tue, 13 Apr 2010 05:16:30 +0000

"It's been two weeks rather than the usual one, because we've been hunting a really annoying VM regression that not a lot of people seem to have seen, but I didn't want to release an -rc4 with it," began Linux creator Linus Torvalds, announcing the 2.6.34-rc4 Linux kernel. He explained, "we had the choice of either reverting all the anon-vma scalability improvements, or finding out exactly what caused the regression and fixing it. And we got pretty close to the point where I was going to just revert it all." Linus continued:

"Absolutely _huge_ kudos to Borislav Petkov who reported the problem and was able to not just reliably reproduce it, but also test new patches to try to narrow things down at a moments notice. The thing took ten days of emails flying back and forth, and Borislav was there all the time, day and night, through several patches that tried to fix it (several real bugs, but not the one he hit) and lots of patches to just add instrumentation to get us nearer to the cause of the problem. And finally, today, confirmation that we actually nailed the problem. So if anybody has been seeing a oops (or sometimes a GP fault) in page_referenced(), that should be gone now."

As for the rest of the changes, Linus noted, "the bulk of the changes come from drivers - a new network driver (cxgb4), but also updates to the radeon and nouveau drivers. And then there is the random updates everywhere." Read on for the full changelog.

Quote: Total Morons When It Comes To VM

Jeremy — Thu, 27 Mar 2008 01:31:34 +0000

"I realize that getting the POWER people to accept that they have been total morons when it comes to VM for the last three decades is hard, but somebody in the POWER hardware design camp should (a) be told and (b) be really ashamed of themselves."

Quote: The VM Is Hard

Jeremy — Wed, 23 Jan 2008 23:15:58 +0000

"Yes, the VM is hard. I agree. It's nasty. But exactly because it's nasty and subtle and horrid, I'm also very anal about it, and I get really nervous when somebody touches it without (a) knowing all the rules intimately and (b) listening to people who do."

NetBSD Summer of Code Summary

Jeremy — Tue, 09 Oct 2007 11:22:56 +0000

Mark Weinem offered a summary of NetBSD's six 2007 Summer of Code development projects. The projects included: the Automated Testing Framework, "the goal of the ATF project was to develop a testing framework to easily define test cases and run them in a completely automated way"; porting ZFS, "the primary goal of this project was to port volume emulation (ZVOL) functionality in order to mount ZFS file systems"; QoS framework for NetBSD's virtual memory system, "for delay sensitive systems such as streaming multimedia servers and back-end database systems, servicing the reader processes in a timely fashion is more important than the servicing the writers"; kernel file systems in userspace, as a result of the project, "almost all NetBSD kernel file systems can be compiled, mounted and run in userspace"; and hardware monitoring, "the aim of this project was to develop a kernel event notification framework to notify userland of hardware changes e.g. a new USB device being added". Mark added:

"NetBSD has been involved in the Google Summer of Code since its conception in 2005. This year we were glad to once again have the oppertunity to introduce six students to our operating system, to Open Source software development and get them sponsored by Google to work on projects defined by the NetBSD developers."

Avoiding Unnecessary Delays

Jeremy — Fri, 28 Sep 2007 00:21:10 +0000

"We don't want to introduce pointless delays in throttle_vm_writeout() when the writeback limits are not yet exceeded, do we?" asked Fengguang Wu as the description of his patch to mm/page-writeback.c. Andrew Morton replied, "this is a pretty major bugfix, explaining, "this patch has the potential to significantly alter the dynamics of the VM behaviour under particular workloads. It might turn up other stuff..." He continued:

"I wonder why nobody noticed this happening. Either a) it turns out that kswapd is doing a good job and such callers don't do direct reclaim much or b) nobody is doing any in-depth kernel instrumentation.

"Now, how _would_ one notice this problem? We don't have very good tools, really. Booting with "profile=sleep" and looking at the profile data would be one way. Repeatedly doing sysrq-T is another. Perhaps the new lockstat-via-lockdep code would allow this to be observed in some fashion, dunno."