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

From: Badari Pulavarty
Date: Wed Jun 15 2005 - 16:21:44 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/