| To: | Nathan Scott <nathans@xxxxxxx> |
|---|---|
| Subject: | Re: Process stuck in R state at extent = 2049 |
| From: | Sakai Yasutoshi <sakai-yasutoshi@xxxxxxxxxxxxx> |
| Date: | Fri, 10 Dec 2004 16:09:11 +0900 |
| Cc: | linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <20041207001319.GB993@frodo> |
| References: | <F7E62874-472D-11D9-93AD-003065E619BC@xxxxxxxxxxxxx> <20041207001319.GB993@frodo> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
On 2004/12/07, at 9:13, Nathan Scott wrote: On Mon, Dec 06, 2004 at 11:24:34AM +0900, Sakai Yasutoshi wrote:Hi. We are running linux 2.4.26 on IBM PPC405GP. Sometimes our process stuck in 'R' state when number of extent reaches 2049.And disk cache is freed at same time, so we have 40Mbyte of free memory,but we get kernel message "kernel: __alloc_pages: 4-order allocation failed (gfp=0xf0/0)".Process reverts to normal state after 5 seconds to 20 minutes once in awhile. is this XFS problem?Sort of; XFS has a tendency of asking for contiguous pages, and the VM has a tendency of not being able to satisfy such requests -- you might have more luck with a CVS 2.4 kernel, in particular the split-patches/cache_defs patch there adds a mechanism for 2.4 kernels to be able to do memory shaking which the XFS code can plug into. 2.6 provides a mechanism like that, without need for patching (fwiw). It seems this patch fixes our problem. Does XFS need more contiguous pages especially when extents reachs 2049? Thanks. -- Yasutoshi Sakai |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: TAKE 907752 - acl/attr, Nathan Scott |
|---|---|
| Next by Date: | Re: TAKE 907752 - acl/attr, Andreas Gruenbacher |
| Previous by Thread: | Re: Process stuck in R state at extent = 2049, Nathan Scott |
| Next by Thread: | XFS_VERSION_STRING not autoversioning?, zaphodb |
| Indexes: | [Date] [Thread] [Top] [All Lists] |