On Wed 01-06-16 23:38:30, Oleg Nesterov wrote:
> On 06/01, Michal Hocko wrote:
> >
> > On Wed 01-06-16 01:56:26, Oleg Nesterov wrote:
> > > On 05/31, Michal Hocko wrote:
> > > >
> > > > On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> > > > >
> > > > > This single change in get_scan_count() under
On Wed 01-06-16 23:38:30, Oleg Nesterov wrote:
> On 06/01, Michal Hocko wrote:
> >
> > On Wed 01-06-16 01:56:26, Oleg Nesterov wrote:
> > > On 05/31, Michal Hocko wrote:
> > > >
> > > > On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> > > > >
> > > > > This single change in get_scan_count() under
On 06/01, Michal Hocko wrote:
>
> On Wed 01-06-16 01:56:26, Oleg Nesterov wrote:
> > On 05/31, Michal Hocko wrote:
> > >
> > > On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> > > >
> > > > This single change in get_scan_count() under for_each_evictable_lru()
> > > > loop
> > > >
> > > >
On 06/01, Michal Hocko wrote:
>
> On Wed 01-06-16 01:56:26, Oleg Nesterov wrote:
> > On 05/31, Michal Hocko wrote:
> > >
> > > On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> > > >
> > > > This single change in get_scan_count() under for_each_evictable_lru()
> > > > loop
> > > >
> > > >
On Wed 01-06-16 01:56:26, Oleg Nesterov wrote:
> On 05/31, Michal Hocko wrote:
> >
> > On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> > >
> > > This single change in get_scan_count() under for_each_evictable_lru() loop
> > >
> > > - size = lruvec_lru_size(lruvec, lru);
> > > +
On Wed 01-06-16 01:56:26, Oleg Nesterov wrote:
> On 05/31, Michal Hocko wrote:
> >
> > On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> > >
> > > This single change in get_scan_count() under for_each_evictable_lru() loop
> > >
> > > - size = lruvec_lru_size(lruvec, lru);
> > > +
On 05/31, Michal Hocko wrote:
>
> On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> >
> > This single change in get_scan_count() under for_each_evictable_lru() loop
> >
> > - size = lruvec_lru_size(lruvec, lru);
> > + size = zone_page_state_snapshot(lruvec_zone(lruvec),
> >
On 05/31, Michal Hocko wrote:
>
> On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> >
> > This single change in get_scan_count() under for_each_evictable_lru() loop
> >
> > - size = lruvec_lru_size(lruvec, lru);
> > + size = zone_page_state_snapshot(lruvec_zone(lruvec),
> >
On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> sorry for delay,
>
> On 05/25, Michal Hocko wrote:
[...]
> > This is a bit surprising but my testing shows that the result shouldn't
> > make much difference. I can see some discrepancies between lru_vec size
> > and zone_reclaimable_pages but they
On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> sorry for delay,
>
> On 05/25, Michal Hocko wrote:
[...]
> > This is a bit surprising but my testing shows that the result shouldn't
> > make much difference. I can see some discrepancies between lru_vec size
> > and zone_reclaimable_pages but they
sorry for delay,
On 05/25, Michal Hocko wrote:
>
> On Wed 25-05-16 00:43:41, Oleg Nesterov wrote:
> >
> > But. It _seems to me_ that the kernel "leaks" some pages in
> > LRU_INACTIVE_FILE
> > list because inactive_file_is_low() returns the wrong value. And do not even
> > ask me why I think so,
sorry for delay,
On 05/25, Michal Hocko wrote:
>
> On Wed 25-05-16 00:43:41, Oleg Nesterov wrote:
> >
> > But. It _seems to me_ that the kernel "leaks" some pages in
> > LRU_INACTIVE_FILE
> > list because inactive_file_is_low() returns the wrong value. And do not even
> > ask me why I think so,
On 05/24, Michal Hocko wrote:
>
> On Mon 23-05-16 17:14:19, Oleg Nesterov wrote:
> > On 05/23, Michal Hocko wrote:
> [...]
> > > Could you add some tracing and see what are the numbers
> > > above?
> >
> > with the patch below I can press Ctrl-C when it hangs, this breaks the
> > endless loop and
On 05/24, Michal Hocko wrote:
>
> On Mon 23-05-16 17:14:19, Oleg Nesterov wrote:
> > On 05/23, Michal Hocko wrote:
> [...]
> > > Could you add some tracing and see what are the numbers
> > > above?
> >
> > with the patch below I can press Ctrl-C when it hangs, this breaks the
> > endless loop and
On Mon 23-05-16 17:14:19, Oleg Nesterov wrote:
> On 05/23, Michal Hocko wrote:
[...]
> > Could you add some tracing and see what are the numbers
> > above?
>
> with the patch below I can press Ctrl-C when it hangs, this breaks the
> endless loop and the output looks like
>
> vmscan:
On Mon 23-05-16 17:14:19, Oleg Nesterov wrote:
> On 05/23, Michal Hocko wrote:
[...]
> > Could you add some tracing and see what are the numbers
> > above?
>
> with the patch below I can press Ctrl-C when it hangs, this breaks the
> endless loop and the output looks like
>
> vmscan:
On 05/23, Michal Hocko wrote:
>
> > nr_scanned = zone_page_state(zone, NR_PAGES_SCANNED);
> > if (nr_scanned)
> > __mod_zone_page_state(zone, NR_PAGES_SCANNED, -nr_scanned);
> >
> > and this doesn't look exactly right: zone_page_state() ignores the per-cpu
> > ->vm_stat_diff[]
On 05/23, Michal Hocko wrote:
>
> > nr_scanned = zone_page_state(zone, NR_PAGES_SCANNED);
> > if (nr_scanned)
> > __mod_zone_page_state(zone, NR_PAGES_SCANNED, -nr_scanned);
> >
> > and this doesn't look exactly right: zone_page_state() ignores the per-cpu
> > ->vm_stat_diff[]
Hi,
Tetsuo has already pointed you at my oom detection rework which removes
the zone_reclaimable ugliness (btw. one of the top reasons to rework
this area) and it is likely to fix your problem. I would still like to
understand what happens with your test case because we might want to
prepare a
Hi,
Tetsuo has already pointed you at my oom detection rework which removes
the zone_reclaimable ugliness (btw. one of the top reasons to rework
this area) and it is likely to fix your problem. I would still like to
understand what happens with your test case because we might want to
prepare a
On 05/21, Tetsuo Handa wrote:
>
> On 2016/05/21 5:28, Oleg Nesterov wrote:
> > It spins in __alloc_pages_slowpath() forever, __alloc_pages_may_oom() is
> > never
> > called, it doesn't react to SIGKILL, etc.
> >
> > This is because zone_reclaimable() is always true in shrink_zones(), and the
> >
On 05/21, Tetsuo Handa wrote:
>
> On 2016/05/21 5:28, Oleg Nesterov wrote:
> > It spins in __alloc_pages_slowpath() forever, __alloc_pages_may_oom() is
> > never
> > called, it doesn't react to SIGKILL, etc.
> >
> > This is because zone_reclaimable() is always true in shrink_zones(), and the
> >
On 2016/05/21 5:28, Oleg Nesterov wrote:
> Hello,
>
> Recently I hit the problem, _sometimes_ the system just hangs in OOM
> situation.
> Surprisingly, this time OOM-killer is innocent ;) and finally I can reproduce
> this more-or-less reliably just running
>
> #include
> #include
On 2016/05/21 5:28, Oleg Nesterov wrote:
> Hello,
>
> Recently I hit the problem, _sometimes_ the system just hangs in OOM
> situation.
> Surprisingly, this time OOM-killer is innocent ;) and finally I can reproduce
> this more-or-less reliably just running
>
> #include
> #include
Hello,
Recently I hit the problem, _sometimes_ the system just hangs in OOM situation.
Surprisingly, this time OOM-killer is innocent ;) and finally I can reproduce
this more-or-less reliably just running
#include
#include
int main(void)
{
for
Hello,
Recently I hit the problem, _sometimes_ the system just hangs in OOM situation.
Surprisingly, this time OOM-killer is innocent ;) and finally I can reproduce
this more-or-less reliably just running
#include
#include
int main(void)
{
for
26 matches
Mail list logo
