On Tue, Sep 09, 2008 at 05:10:41PM +0000, Deepak Saxena wrote: > > * We need to find out why the oom-killer is not killing things fast > > enough. Based on our results, we might consider configuring > > /proc/$pid/oom_adj to preferentially kill some processes (e.g., the > > foreground [or background?] activities.) > > In the cases I've been playing with, browse is the only activity that > is running. Will try bumping its oom_adj to see if this improves OOM > kill latency.
Did 'echo 15 > /proc/pid/oom_adj`' and this does not help much. The system starts getting laggy at the point we reach about 3M remaining memory (according to top) but the OOM killer does not actually kick in until we fail an allocation which happens sometime in later. Need to capture what is happening at the kernel level during this window though I don't think that fixing this at the OOM killer layer is doable for 8.2. > I have yet to see an actual deadlock. What I saw when trying to > reproduce #3816 is that the OOM killer just takes a very very long > time to kick in. > > > - whether our kernel "overcommits" when allocation requests are made? > > By default vm.overcommit_memory is set to 0 which will refuse "Obvious > overcommits of address space". I will try setting this to 3 along with > vm.overcommit_ratio to 0 to force no overcommit at all and see how the > system reacts. This didn't quite do what I expected as I missread the docs. If we set overcommit_ratio=100 and overcommit_memory=3, the kernel will not overcommit memory and we end up with Browse crashing "gracefully" w/o bogging down the whole system or with Browse just "gracefully" ignoring any user input in the address bar due to probably a failed allocation of some sort when creating a new webpage instance. ~Deepak _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
