Messages in this thread | | | Date | Thu, 5 Apr 2012 13:31:53 -0700 | From | Mel Gorman <> | Subject | Re: [ 101/175] mm: vmscan: forcibly scan highmem if there are too many buffer_heads pinning highmem |
| |
Sorry for the slow response. I was at LSF/MM and still at Collaboration Summit and not keeping up with mail.
On Tue, Apr 03, 2012 at 04:01:33AM +0100, Ben Hutchings wrote:
> On Fri, 2012-03-30 at 12:50 -0700, Greg KH wrote: > > 3.3-stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Mel Gorman <mel@csn.ul.ie> > > > > commit cc715d99e529d470dde2f33a6614f255adea71f3 upstream. > > > > Stuart Foster reported on bugzilla that copying large amounts of data > > from NTFS caused an OOM kill on 32-bit X86 with 16G of memory. Andrew > > Morton correctly identified that the problem was NTFS was using 512 > > blocks meaning each page had 8 buffer_heads in low memory pinning it. > > I notice that this was not applied to 3.0.26 or 3.2.14. >
True.
> [...] > > Addresses https://bugzilla.kernel.org/show_bug.cgi?id=42578 > [...] > > but this bug was reported against 3.1.9, so the fix is presumably needed > for 3.2 at least. > > Presumably the upstream change doesn't apply cleanly and would need to > be backported. Is anyone planning to do that? >
It probably does not apply cleanly and considering how the bug is triggered I was not treating it as a high priority. Nikola Ciprich (added to cc) had said that he might try backporting it and I would review the result. I have not heard anything since. I can take a look at backporting it next week if it is considered a common problem.
-- Mel Gorman SUSE Labs
| |