Re: Kernel fails on Dreamcast - results of bisection

[Paul Mundt <lethal@linux-sh.org>]

On Sun, Mar 22, 2009 at 06:30:46PM +0000, Adrian McMenamin wrote:
> On Mon, 2009-03-23 at 00:43 +0900, Paul Mundt wrote:
> > On Sun, Mar 22, 2009 at 01:49:46PM +0000, Adrian McMenamin wrote:
> > > On Sun, 2009-03-22 at 20:13 +0900, Paul Mundt wrote:
> > > > On Sat, Mar 21, 2009 at 11:39:25PM +0000, Adrian McMenamin wrote:
> > > > > (I am now getting a lot of messages about failures of the udev script -
> > > > > possibly because I have just turned a lot of debugging stuff on - in any
> > > > > case the system does boot and works with that commit reverted).
> > > > > 
> > > > These messages are about allocation failures, the exact same thing that
> > > > leads to your OOM. (It does help to actually read the error messages
> > > > rather than dismiss them as superfluous). While it is possible that the
> > > > timer patch pushed you over the edge on memory allocation, nothing else
> > > > suggests that you have pinpointed the real problem. Obviously udev did
> > > > not used to hit allocation failures, and we need to know when that
> > > > started, or what you did to your environment that causes it.
> > > > --
> > > 
> > > Could you explain what you mean by "These messages are about allocation
> > > failures, the exact same thing that leads to your OOM."
> > > 
> > It seems pretty self evident. If a virtual filesystem is returning
> > allocation failures, you have a problem, and you need to figure out why
> > you are getting those allocation failures from udev. The timer patch
> > might cause enough pressure that it makes the problem manifest in an oops
> > more readily, but your system is completely broken or without the timer
> > patch if you can't allocate pages to create device nodes, period.
> > 
> > > Isn't one a failure to allocate space on a block device and the other
> > > running out of memory, or have I missed something?
> > > 
> > What do you think the backing store for udev is?
> 
> 
> 
> It's memory use is arbitrarily set in a config file. It's not the same
> as running out of memory, just reaching that limit.
> 
No, it's not the same as running out of memory, but at no point did I
suggest it was, only that it served to increase pressure, and that if you
were already hitting allocation failures from that alone, then whether
something on the kernel side pushes the system in to an OOM condition on
top of that is hardly the root issue.

> In any case I have not been able to reproduce those messages without the
> debug options set to the max, but I have certainly been able to
> reproduce the OOM condition.
> 
> There is clearly a regression here. I am puzzled about why you seem so
> anxious not to acknowledge that there is.
> 
I am aware of the fact there is a regression, my point is that it seems
something got broken much earlier and that the timer change in question
is ultimately not the main issue. In the kernel we prefer to debug and
fix root problems rather than the symptoms that fall out of them. If you
don't wish to bisect down to the point where you didn't get allocation
failures in userspace, that is likewise entirely up to you.