Right now before OOPS:
Mem: 62244K av, 61292K used, 952K free, 0K shrd, 1496K buff
Swap: 467444K av, 37344K used, 430100K free 29528K cached
I got a lot of things running, several daemons, netscape, and other things. I put
a 400MB swap for now just to help things.
Here's what happens after oops:
Wait a second...before I didn't have the 400MB swap on, and I had about 952K of
physical ram left. Shouldn't it try and swap if it cant get enough physical
memory?
It did NOT oops with that amount of swap:
If i turn it off:
Mem: 62244K av, 61288K used, 956K free, 0K shrd, 1448K buff
Swap: 64252K av, 38024K used, 26228K free 29880K cached
and try the xcdrgtk (X CDRoaster)
I get...hrm.. this is really strange. Now its not ooping?!
I dont know it must have to do with something somewhere I cant tell you.
Mike Galbraith wrote:
> On Sun, 25 Feb 2001, Shawn Starr wrote:
>
> > Unsure, the system remains stable after the fault though, strangely /dev/dsp
> > becomes "busy". I suspect it has to do with this somehow.. but im not sure.
> > I submitted a ksymoops dump, maybe that can help.
>
> Drop to single user and do a whopping big dd or iozone or bonnie
> and see what free reports afterward. If much of your ram becomes
> available, it's not a leak.
>
> -Mike
The way sg_low_malloc() tries to allocate, failure messages are
pretty much garanteed. It tries high order allocations (which
are unreliable even when not stressed) and backs off until it
succeeds.
In other words, the messages are a red herring.
-Mike
Well, I Discovered, something strange. I put in a blank new CD-R, so these
errors are not of concern? (In which case why have the kernel log get
spewed with them if they are guaranteed to happen?)
Shawn.
--
Hugged a Tux today? (tm)
On Sun, 25 Feb 2001, Mike Galbraith wrote:
> The way sg_low_malloc() tries to allocate, failure messages are
> pretty much garanteed. It tries high order allocations (which
> are unreliable even when not stressed) and backs off until it
> succeeds.
>
> In other words, the messages are a red herring.
>
> -Mike
>
>
>
On Sun, 25 Feb 2001, Mike Galbraith wrote:
> The way sg_low_malloc() tries to allocate, failure messages are
> pretty much garanteed. It tries high order allocations (which
> are unreliable even when not stressed) and backs off until it
> succeeds.
>
> In other words, the messages are a red herring.
Yup. And they should not be printed.
We can add an allocation flag (__GFP_NO_CRITICAL?) which can be used by
sg_low_malloc() (and other non critical allocations) to fail previously
and not print the message.
Linus ?
> We can add an allocation flag (__GFP_NO_CRITICAL?) which can be used by
> sg_low_malloc() (and other non critical allocations) to fail previously
> and not print the message.
It is just for debugging. The message can go. If anytbing it would be more
useful to tack Failed alloc data on the end of /proc/slabinfo
On Mon, 26 Feb 2001, Alan Cox wrote:
> > We can add an allocation flag (__GFP_NO_CRITICAL?) which can be used by
> > sg_low_malloc() (and other non critical allocations) to fail previously
> > and not print the message.
>
> It is just for debugging. The message can go. If anytbing it would be more
> useful to tack Failed alloc data on the end of /proc/slabinfo
The issue is not the warn message.
Non critical allocations (such as this case of sg_low_malloc()) are trying
to get additional memory to optimize things -- we want the allocator to be
lazy and fail previously instead doing hard work. If kswapd cannot keep up
with the memory pressure, we're surely in a memory shortage state.
Its better to get out of the memory shortage instead running into OOM
because of some optimization, I guess.
Another example of such a flag is swapin readahead.
It may not be an important message but what does happen is /dev/dsp becomes
hung and no sound works after the fault. So something is definately wrong.
Shawn.
Marcelo Tosatti wrote:
> On Mon, 26 Feb 2001, Alan Cox wrote:
>
> > > We can add an allocation flag (__GFP_NO_CRITICAL?) which can be used by
> > > sg_low_malloc() (and other non critical allocations) to fail previously
> > > and not print the message.
> >
> > It is just for debugging. The message can go. If anytbing it would be more
> > useful to tack Failed alloc data on the end of /proc/slabinfo
>
> The issue is not the warn message.
>
> Non critical allocations (such as this case of sg_low_malloc()) are trying
> to get additional memory to optimize things -- we want the allocator to be
> lazy and fail previously instead doing hard work. If kswapd cannot keep up
> with the memory pressure, we're surely in a memory shortage state.
>
> Its better to get out of the memory shortage instead running into OOM
> because of some optimization, I guess.
>
> Another example of such a flag is swapin readahead.
--
Hugged a Tux today? (tm)
On Mon, 26 Feb 2001, Shawn Starr wrote:
> It may not be an important message but what does happen is /dev/dsp becomes
> hung and no sound works after the fault. So something is definately wrong.
Do you mean it hangs without the BUG() inserted, or only after the oops?
-Mike
When added with BUG(); it will hang /dev/dsp.
I'm not sure if it did without it. I'll be restarting with the removed
BUG(); soon.
On Tue, 27 Feb 2001, Mike Galbraith wrote:
> On Mon, 26 Feb 2001, Shawn Starr wrote:
>
> > It may not be an important message but what does happen is /dev/dsp becomes
> > hung and no sound works after the fault. So something is definately wrong.
>
> Do you mean it hangs without the BUG() inserted, or only after the oops?
>
> -Mike
>
>
>
On Tue, 27 Feb 2001, Shawn Starr wrote:
> When added with BUG(); it will hang /dev/dsp.
If the device is opened and we oops before closing it, subsequent
open attempts will fail (busy). If it hangs after a failed high
order allocation attempt without the BUG() insertion, that could
be called a driver bug.
-Mike