| To: | Sean Noonan <Sean.Noonan@xxxxxxxxxxxx> |
|---|---|
| Subject: | Re: XFS memory allocation deadlock in 2.6.38 |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Thu, 24 Mar 2011 09:03:45 +1100 |
| Cc: | "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>, Martin Bligh <Martin.Bligh@xxxxxxxxxxxx>, Trammell Hudson <Trammell.Hudson@xxxxxxxxxxxx> |
| In-reply-to: | <081DDE43F61F3D43929A181B477DCA95639B532C@xxxxxxxxxxxxxxxxxxxx> |
| References: | <081DDE43F61F3D43929A181B477DCA95639B52E8@xxxxxxxxxxxxxxxxxxxx> <20110322232504.GC15270@dastard> <081DDE43F61F3D43929A181B477DCA95639B532C@xxxxxxxxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.20 (2009-06-14) |
On Wed, Mar 23, 2011 at 05:33:36PM -0400, Sean Noonan wrote: > > What is the configuration of the machine you are testing on? I can't > > reproduce this on a current 2.6.39-tot tree on a 2p/2GB RAM VM that > > has it's blockdev images on a single SATA drive.... > > The machine we are testing with has 12 cores, 12 hyperthreaded > siblings, and 48GB of RAM. The filesystem is backed by a > partition on one large hardware RAID. There is a second bug we've > run into that I'll report tomorrow. So why would creating a 16GB file cause and OOM condition if you have 48GB RAM? That doesn't make a whole lot of sense to me. Is that memory free, of are other things running and consuming memory? > Could you point me to the current tree you are working with? > 2.6.39-tot doesn't mean anything to me. tot = Top of Tree. IOWs, 2.6.39-tot means the latest development kernel Linus has released. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx |
| Previous by Date: | RE: XFS memory allocation deadlock in 2.6.38, Sean Noonan |
|---|---|
| Next by Date: | RE: XFS memory allocation deadlock in 2.6.38, Sean Noonan |
| Previous by Thread: | RE: XFS memory allocation deadlock in 2.6.38, Sean Noonan |
| Next by Thread: | RE: XFS memory allocation deadlock in 2.6.38, Sean Noonan |
| Indexes: | [Date] [Thread] [Top] [All Lists] |