Re: adding swap workarounds oom - was: Re: Out of Memory: Killed process 16498 (java).

[Jens Axboe <axboe@suse.de>]

On Wed, Mar 01 2006, Andi Kleen wrote:
> On Wednesday 01 March 2006 13:19, Jens Axboe wrote:
> > On Wed, Mar 01 2006, Jens Axboe wrote:
> > > On Wed, Mar 01 2006, Andy Chittenden wrote:
> > > 
> > > Some weird stuff going on here, or I'm confused. Lots of entries are not
> > > page start aligned, yet they have a length of 4kb. The troublesome
> > > entries are additionally:
> > > 
> > > > hda: DMA table too small
> > > > ide dma table, 256 entries, bounce pfn 1310720
> > > > sg0: dma=6e9e800, len=4096/0, pfn=1185312
> > > > sg1: dma=6e9f800, len=4096/0, pfn=1185270
> > > 
> > > This one, since it'll wrap around and consume two cpu dma table entries.
> > > Since we are already at the max of 256 already from the beginning,
> > > there's no way we can split this one.
> > > 
> > > > sg2: dma=6ea0800, len=4096/0, pfn=1184892
> > > > sg3: dma=6ea1800, len=4096/0, pfn=1185144
> > > > sg4: dma=6ea2800, len=4096/0, pfn=1185102
> > > > sg5: dma=6ea3800, len=4096/0, pfn=1185059
> > > > sg6: dma=6ea4800, len=4096/0, pfn=1185017
> > > > sg7: dma=6ea5800, len=4096/0, pfn=1184975
> > > > sg8: dma=6ea6800, len=4096/0, pfn=1184933
> > > > sg9: dma=6ea7800, len=4096/0, pfn=1184850
> > > > sg10: dma=6ea8800, len=4096/0, pfn=1186142
> > > > sg11: dma=6ea9800, len=4096/0, pfn=1186814
> > > > sg12: dma=6eaa800, len=4096/0, pfn=1186731
> > > > sg13: dma=6eab800, len=4096/0, pfn=1186689
> > > > sg14: dma=6eac800, len=4096/0, pfn=1186227
> > > > sg15: dma=6ead800, len=4096/0, pfn=1186185
> > > > sg16: dma=6eae800, len=4096/0, pfn=1186100
> > > > sg17: dma=6eaf800, len=4096/0, pfn=1185807
> > > 
> > > Ditto for that one, will also be split into two 2kb entries.
> > > 
> > > So this first mapping dump shows us that we start with 256 entries, that
> > > IDE would like to map into 258 entries. The question is why these dma
> > > address as mapped by pci_map_sg() aren't page aligned? Andi?
> > 
> > Oh, it's dumping ->length but should be dumping ->dma_length in my debug
> > patch. Can you change that and reproduce again?
> 
> Also only dump upto the value map_sg returned.

It is dumping that far only, i and sg_nents is the value returned by
pci_map_sg()

> The new kernel will not do any changes to the input parts in the
> sglist, but just merge up the dma pointers and fix up dma_length.  So
> the mappings can be completely out of sync now.

Yeah that's fine, it's my debug patch that dumps ->length (input) that
is wrong.

It'll be interesting to see, I wonder why so many of the output dma
address aren't aligned.

-- 
Jens Axboe

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