Re: [BUG?] OOM with large cache....(x86_64, 2.6.24-rc3-git1, nohz)

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Tuesday 20 November 2007 20:09, Ian Kumlien wrote:
> On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote:

> > It's also used up all your 2.5GB of swap. The output of your `free` shows
> > a fair bit of disk cache there, but it also shows a lot of swap free,
> > which isn't the case at oom-time.
>
> Yes, as i said those was from several hours later...

OK, missed that.


> > Unfortunately, we don't show NR_ANON_PAGES in these stats, but at a
> > guess, I'd say that the file cache is mostly shrunk and you still don't
> > have enough memory. trackerd probably has a memory leak in it, or else is
> > just trying to allocate more memory than you have. Is this a regression?
>
> I have had it happen twice before, without tracker running...

Does the machine recover afterward, or is the memory freed up after
the OOM kill? How about if you kill X and do a sysrq+E then sysrq+I
(to kill all tasks)?

If the memory still isn't freed after that, then we could have a
kernel memory leak.


> It didn't quite get to the oom stage, it just failed alot of allocations
> while having 1.5 or more memory locked in cache.
>
> http://marc.info/?l=linux-kernel&m=118895576924867&w=2

OK, yes this is a different case, and it is very far off the OOM
killing stage. Atomic allocations can fail quite easily, but
kswapd will have started up and will start freeing memory.

Actually there are some patches gone into 2.6.24 that have fixed
some corner cases with the network stack making order-1 allocations
when it should be order-0. That might help your atomic allocation
failures, but they aren't really a bug anyway (unless networking
fails to recover).

Thanks for reporting all this...
-
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/