Re: 2.6.22-stable causes oomkiller to be invoked
From: Christoph Lameter
Date: Wed Jan 02 2008 - 15:46:13 EST
On Fri, 28 Dec 2007, Dhaval Giani wrote:
> we managed to get your required information. Last 10,000 lines are
> attached (The uncompressed file comes to 500 kb).
>
> Hope it helps.
Somehow the nr_pages field is truncated to 16 bit and it
seems that there are sign issues there? We are wrapping around....
q->nr_pages is 36877, min_pages is 25 ----> swapper
q->nr_pages is 46266, min_pages is 25 ----> bash
q->nr_pages is 36877, min_pages is 25 ----> swapper
q->nr_pages is 36877, min_pages is 25 ----> swapper
q->nr_pages is 46265, min_pages is 25 ----> bash
q->nr_pages is 46265, min_pages is 25 ----> cat
q->nr_pages is 36877, min_pages is 25 ----> swapper
q->nr_pages is 46265, min_pages is 25 ----> cat
q->nr_pages is 36877, min_pages is 25 ----> swapper
q->nr_pages is 0, min_pages is 25 ----> swapper
q->nr_pages is 36877, min_pages is 25 ----> swapper
q->nr_pages is 36877, min_pages is 25 ----> swapper
q->nr_pages is 46265, min_pages is 25 ----> cat
An int is just a 16 bit field on i386? I thought it was 32 bits? Or is
the result due to the way that systemtap works?
Could you post the neighboring per cpu variables to quicklist (look at the
System.map). Maybe somehow we corrupt the nr_pages and page contents.
Also could you do another systemtap and also print out the current
processor? Maybe nr_pages gets only corrupted on a specific processor. I
see a zero there and sometimes other sane values.
--
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/