Dear Fengguang (et al),
> There are 260MB reclaimable slab pages in the normal zone, however we
> somehow failed to reclaim them. ...
Could the problem be that without CONFIG_NUMA, zone_reclaim_mode stays
at zero and anyway zone_reclaim() does nothing in include/linux/swap.h ?
Though... there is
Dear Fengguang,
> There are 260MB reclaimable slab pages in the normal zone ...
Marked "all_unreclaimable? yes": is that wrong? Question asked also in:
http://marc.info/?l=linux-mm&m=135873981326767&w=2
> ... however we somehow failed to reclaim them. ...
I made a patch that would do a drop_cac
On Fri, Jan 25, 2013 at 10:43:45AM +1100, paul.sz...@sydney.edu.au wrote:
> Dear Fengguang,
>
> > Or more simple, you may show us the OOM dmesg which will contain the
> > number of dirty pages. ...
>
> Do you mean kern.log lines like:
Yes.
> [ 744.754199] bash invoked oom-killer: gfp_mask=0xd0
Dear Jan,
> I think he found the culprit of the problem being min_free_kbytes was not
> properly reflected in the dirty throttling. ... Paul please correct me
> if I'm wrong.
Sorry but have to correct you.
I noticed and patched/corrected two problems, one with (setpoint-dirty)
in bdi_position_ra
Dear Fengguang,
> Or more simple, you may show us the OOM dmesg which will contain the
> number of dirty pages. ...
Do you mean kern.log lines like:
[ 744.754199] bash invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0,
oom_score_adj=0
[ 744.754202] bash cpuset=/ mems_allowed=0
[ 744.7542
On Thu 24-01-13 22:57:07, Wu Fengguang wrote:
> Hi Paul,
>
> > (This patch does not solve the PAE OOM issue.)
>
> You may try the below debug patch. The only way the writeback patches
> should trigger OOM, I think, is for the number of dirty/writeback
> pages going out of control.
>
> Or more si
Hi Paul,
> (This patch does not solve the PAE OOM issue.)
You may try the below debug patch. The only way the writeback patches
should trigger OOM, I think, is for the number of dirty/writeback
pages going out of control.
Or more simple, you may show us the OOM dmesg which will contain the
numbe
On Wed, Jan 23, 2013 at 12:54:38AM +0100, Jan Kara wrote:
> On Sun 20-01-13 11:02:10, paul.sz...@sydney.edu.au wrote:
> > In bdi_position_ratio(), get difference (setpoint-dirty) right even when
> > negative. Both setpoint and dirty are unsigned long, the difference was
> > zero-padded thus wrongly
On Sun 20-01-13 11:02:10, paul.sz...@sydney.edu.au wrote:
> In bdi_position_ratio(), get difference (setpoint-dirty) right even when
> negative. Both setpoint and dirty are unsigned long, the difference was
> zero-padded thus wrongly sign-extended to s64. This issue affects all
> 32-bit architectur
In bdi_position_ratio(), get difference (setpoint-dirty) right even when
negative. Both setpoint and dirty are unsigned long, the difference was
zero-padded thus wrongly sign-extended to s64. This issue affects all
32-bit architectures, does not affect 64-bit architectures where long
and s64 are eq
10 matches
Mail list logo
