Re: 2.6.12-rc6-mm1 & 2K lun testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2005-06-15 at 12:02, Nick Piggin wrote:
> Badari Pulavarty wrote:
> > On Wed, 2005-06-15 at 11:30, Nick Piggin wrote:
> > 
> >>Badari Pulavarty wrote:
> >>
> >>
> >>>------------------------------------------------------------------------
> >>>
> >>>elm3b29 login: dd: page allocation failure. order:0, mode:0x20
> >>>
> >>>Call Trace: <IRQ> <ffffffff801632ae>{__alloc_pages+990} <ffffffff801668da>{cache_grow+314}
> >>>       <ffffffff80166d7f>{cache_alloc_refill+543} <ffffffff80166e86>{kmem_cache_alloc+54}
> >>>       <ffffffff8033d021>{scsi_get_command+81} <ffffffff8034181d>{scsi_prep_fn+301}
> >>
> >>They look like they're all in scsi_get_command.
> >>I would consider masking off __GFP_HIGH in the gfp_mask of that
> >>function, and setting __GFP_NOWARN. It looks like it has a mempoolish
> >>thingy in there, so perhaps it shouldn't delve so far into reserves.
> > 
> > 
> > You want me to take off GFP_HIGH ? or just set GFP_NOWARN with GFP_HIGH
> > ?
> > 
> 
> Yeah, take off GFP_HIGH and set GFP_NOWARN (always). I would be
> interested to see how that goes.
> 
> Obviously it won't eliminate your failures there (it will probably
> produce more of them), however it might help the scsi command
> allocation from overwhelming the system.

Hmm.. seems to help little. IO rate is not great (compared to 90MB/sec
with "raw") - but machine is making progress. But again, its pretty
unresponsive.

Thanks,
Badari

procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy
id wa
131 254  34896  31328   2540 4982740    0    0    29 101877 1086 11220 
0 100  0  0
149 268  34896  32824   2536 4983712   13    0    42 39505  439  4454  0
100  0  0
135 254  34896  31112   2536 4984768   11    0    20 36233  373  4078  0
100  0  0
130 242  34896  32600   2536 4987364    6    0   161 33626  377  3957  0
100  0  0
153 263  34896  32592   2532 4993560    0    0    14 37124  385  4468  0
100  0  0
144 236  34896  32668   2548 5013148    6    0   154 220366 2360 27530 
0 100  0  0
112 243  34896  34636   2544 5011112    5    0    62 79160  850 10540  0
100  0  0
103 234  34896  31980   2544 5014744    0    0   135 33814  363  4511  0
100  0  0
112 230  34896  32204   2552 5012156    0    0   140 33200  378  4812  0
100  0  0
139 212  34896  32832   2528 5020928   31    0   542 142834 1536 18007 
0 100  0  0
144 215  34896  32896   2528 5019872   17    0    74 41957  449  4781  0
100  0  0
184 252  34896  33252   2504 5024564    0    0    19 34506  374  4616  0
100  0  0
141 240  34896  31624   2516 5026616    0    0   153 31896  378  4904  0
100  0  0


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux