Re: [Stable-review] [48/70] vmscan: all_unreclaimable() usezone->all_unreclaimable as a name

[Ben Hutchings]

On Thu, 2011-04-21 at 13:24 +0900, KOSAKI Motohiro wrote:
> > On Tue, 2011-04-19 at 13:08 -0700, Greg KH wrote:
> > > 2.6.38-stable review patch.  If anyone has any objections, please let us know.
> > > 
> > > ------------------
> > > 
> > > From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
> > > 
> > > commit 929bea7c714220fc76ce3f75bef9056477c28e74 upstream.
> > > 
> > > all_unreclaimable check in direct reclaim has been introduced at 2.6.19
> > > by following commit.
> > > 
> > > 	2006 Sep 25; commit 408d8544; oom: use unreclaimable info
> > > 
> > > And it went through strange history. firstly, following commit broke
> > > the logic unintentionally.
> > > 
> > > 	2008 Apr 29; commit a41f24ea; page allocator: smarter retry of
> > > 				      costly-order allocations
> > [...]
> > 
> > So presumably this needs to be fixed in 2.6.32.y and other longterm
> > series as well.  Though there seems to be a whole series of fixes
> > required in 2.6.32.y!
> > 
> > Are you going to look after that, or should someone else prepare
> > backports?  (I'm certainly not volunteering - I don't have the VM
> > knowledge to work out what needs doing.)
> 
> Hi Ben
> 
> Honestly, I didn't prepare. If my remember is correct, you are debian 
> guy. So, Can I think the backport 2.6.32.y help debian people? If so,
> it's good thing to increase my priority to do this.

Most of the 'enterprise' and long-term supported distributions (Debian,
Ubuntu, SLE, OEL and RHEL) have kernels based on 2.6.32.  RH seem to be
doing their own thing but the rest of us are using 2.6.32.y as a basis.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Attachment: signature.asc
Description: This is a digitally signed message part