On 23.03.2017 09:38, Mike Galbraith wrote:
On Thu, 2017-03-23 at 08:16 +0100, Gerhard Wiesinger wrote:
On 21.03.2017 08:13, Mike Galbraith wrote:
On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
Is this the correct information?
Incomplete, but enough to reiterate cgroup_disable=me
On 2017/03/23 17:38, Mike Galbraith wrote:
> On Thu, 2017-03-23 at 08:16 +0100, Gerhard Wiesinger wrote:
>> On 21.03.2017 08:13, Mike Galbraith wrote:
>>> On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
>>>
Is this the correct information?
>>> Incomplete, but enough to reiterate cg
On Thu, 2017-03-23 at 08:16 +0100, Gerhard Wiesinger wrote:
> On 21.03.2017 08:13, Mike Galbraith wrote:
> > On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
> >
> > > Is this the correct information?
> > Incomplete, but enough to reiterate cgroup_disable=memory
> > suggestion.
> >
>
On 21.03.2017 08:13, Mike Galbraith wrote:
On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
Is this the correct information?
Incomplete, but enough to reiterate cgroup_disable=memory suggestion.
How to collect complete information?
Thnx.
Ciao,
Gerhard
On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote:
> Is this the correct information?
Incomplete, but enough to reiterate cgroup_disable=memory suggestion.
-Mike
On 20.03.2017 04:05, Mike Galbraith wrote:
On Sun, 2017-03-19 at 17:02 +0100, Gerhard Wiesinger wrote:
mount | grep cgroup
Just because controllers are mounted doesn't mean they're populated. To
check that, you want to look for directories under the mount points
with a non-empty 'tasks'. You
On Sun, 2017-03-19 at 17:02 +0100, Gerhard Wiesinger wrote:
> mount | grep cgroup
Just because controllers are mounted doesn't mean they're populated. To
check that, you want to look for directories under the mount points
with a non-empty 'tasks'. You will find some, but memory cgroup
assignment
On 2017/03/19 17:17, Gerhard Wiesinger wrote:
> On 17.03.2017 21:08, Gerhard Wiesinger wrote:
>> On 17.03.2017 18:13, Michal Hocko wrote:
>>> On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
>>> [...]
>
> 4.11.0-0.rc2.git4.1.fc27.x86_64
>
> There are also lockups after some runtime hours to 1
On 19.03.2017 16:18, Michal Hocko wrote:
On Fri 17-03-17 21:08:31, Gerhard Wiesinger wrote:
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
Why does the kernel prefer to swapin/out and not use
a.) the free memory?
It will use all the free mem
On Fri 17-03-17 21:08:31, Gerhard Wiesinger wrote:
> On 17.03.2017 18:13, Michal Hocko wrote:
> >On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
> >[...]
> >>Why does the kernel prefer to swapin/out and not use
> >>
> >>a.) the free memory?
> >It will use all the free memory up to min watermark
On 17.03.2017 21:08, Gerhard Wiesinger wrote:
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
4.11.0-0.rc2.git4.1.fc27.x86_64
There are also lockups after some runtime hours to 1 day:
Message from syslogd@myserver Mar 19 08:22:33 ...
kernel:
On 17.03.2017 18:13, Michal Hocko wrote:
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
Why does the kernel prefer to swapin/out and not use
a.) the free memory?
It will use all the free memory up to min watermark which is set up
based on min_free_kbytes.
Makes sense, how is /proc/
On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]
> Why does the kernel prefer to swapin/out and not use
>
> a.) the free memory?
It will use all the free memory up to min watermark which is set up
based on min_free_kbytes.
> b.) the buffer/cache?
the memory reclaim is strongly biased to
On 16.03.2017 10:39, Michal Hocko wrote:
On Thu 16-03-17 02:23:18, l...@pengaru.com wrote:
On Thu, Mar 16, 2017 at 10:08:44AM +0100, Michal Hocko wrote:
On Thu 16-03-17 01:47:33, l...@pengaru.com wrote:
[...]
While on the topic of understanding allocation stalls, Philip Freeman recently
mailed
On Thu 16-03-17 02:23:18, l...@pengaru.com wrote:
> On Thu, Mar 16, 2017 at 10:08:44AM +0100, Michal Hocko wrote:
> > On Thu 16-03-17 01:47:33, l...@pengaru.com wrote:
> > [...]
> > > While on the topic of understanding allocation stalls, Philip Freeman
> > > recently
> > > mailed linux-kernel wit
On Thu, Mar 16, 2017 at 10:08:44AM +0100, Michal Hocko wrote:
> On Thu 16-03-17 01:47:33, l...@pengaru.com wrote:
> [...]
> > While on the topic of understanding allocation stalls, Philip Freeman
> > recently
> > mailed linux-kernel with a similar report, and in his case there are plenty
> > of
>
On Thu 16-03-17 01:47:33, l...@pengaru.com wrote:
[...]
> While on the topic of understanding allocation stalls, Philip Freeman recently
> mailed linux-kernel with a similar report, and in his case there are plenty of
> page cache pages. It was also a GFP_HIGHUSER_MOVABLE 0-order allocation.
care
On Thu, Mar 16, 2017 at 09:27:14AM +0100, Michal Hocko wrote:
> On Thu 16-03-17 07:38:08, Gerhard Wiesinger wrote:
> [...]
> > The following commit is included in that version:
> > commit 710531320af876192d76b2c1f68190a1df941b02
> > Author: Michal Hocko
> > Date: Wed Feb 22 15:45:58 2017 -0800
>
On Thu 16-03-17 07:38:08, Gerhard Wiesinger wrote:
[...]
> The following commit is included in that version:
> commit 710531320af876192d76b2c1f68190a1df941b02
> Author: Michal Hocko
> Date: Wed Feb 22 15:45:58 2017 -0800
>
> mm, vmscan: cleanup lru size claculations
>
> commit fd538803
On 02.03.2017 08:17, Minchan Kim wrote:
Hi Michal,
On Tue, Feb 28, 2017 at 09:12:24AM +0100, Michal Hocko wrote:
On Tue 28-02-17 14:17:23, Minchan Kim wrote:
On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
On Mon 27-02-17 18:02:36, Minchan Kim wrote:
[...]
>From 9779a1c5d32e2ed
Hi Michal,
On Tue, Feb 28, 2017 at 09:12:24AM +0100, Michal Hocko wrote:
> On Tue 28-02-17 14:17:23, Minchan Kim wrote:
> > On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
> > > On Mon 27-02-17 18:02:36, Minchan Kim wrote:
> > > [...]
> > > > >From 9779a1c5d32e2edb64da5cdfcd6f9737b94
On Tue 28-02-17 14:17:23, Minchan Kim wrote:
> On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
> > On Mon 27-02-17 18:02:36, Minchan Kim wrote:
> > [...]
> > > >From 9779a1c5d32e2edb64da5cdfcd6f9737b94a247a Mon Sep 17 00:00:00 2001
> > > From: Minchan Kim
> > > Date: Mon, 27 Feb 2017
On Tue 28-02-17 07:06:41, Gerhard Wiesinger wrote:
> On 27.02.2017 09:27, Michal Hocko wrote:
> >On Sun 26-02-17 09:40:42, Gerhard Wiesinger wrote:
> >>On 04.01.2017 10:11, Michal Hocko wrote:
> The VM stops working (e.g. not pingable) after around 8h (will be
> restarted
> automatical
On 27.02.2017 09:27, Michal Hocko wrote:
On Sun 26-02-17 09:40:42, Gerhard Wiesinger wrote:
On 04.01.2017 10:11, Michal Hocko wrote:
The VM stops working (e.g. not pingable) after around 8h (will be restarted
automatically), happened serveral times.
Had also further OOMs which I sent to Mincha
On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
> On Mon 27-02-17 18:02:36, Minchan Kim wrote:
> [...]
> > >From 9779a1c5d32e2edb64da5cdfcd6f9737b94a247a Mon Sep 17 00:00:00 2001
> > From: Minchan Kim
> > Date: Mon, 27 Feb 2017 17:39:06 +0900
> > Subject: [PATCH] mm: use up highatomi
On Mon 27-02-17 18:02:36, Minchan Kim wrote:
[...]
> >From 9779a1c5d32e2edb64da5cdfcd6f9737b94a247a Mon Sep 17 00:00:00 2001
> From: Minchan Kim
> Date: Mon, 27 Feb 2017 17:39:06 +0900
> Subject: [PATCH] mm: use up highatomic before OOM kill
>
> Not-Yet-Signed-off-by: Minchan Kim
> ---
> mm/pag
On Sun, Feb 26, 2017 at 09:40:42AM +0100, Gerhard Wiesinger wrote:
> On 04.01.2017 10:11, Michal Hocko wrote:
> >>The VM stops working (e.g. not pingable) after around 8h (will be restarted
> >>automatically), happened serveral times.
> >>
> >>Had also further OOMs which I sent to Mincham.
> >Could
On Sun 26-02-17 09:40:42, Gerhard Wiesinger wrote:
> On 04.01.2017 10:11, Michal Hocko wrote:
> >>The VM stops working (e.g. not pingable) after around 8h (will be restarted
> >>automatically), happened serveral times.
> >>
> >>Had also further OOMs which I sent to Mincham.
> >Could you post them t
On 04.01.2017 10:11, Michal Hocko wrote:
The VM stops working (e.g. not pingable) after around 8h (will be restarted
automatically), happened serveral times.
Had also further OOMs which I sent to Mincham.
Could you post them to the mailing list as well, please?
Still OOMs on dnf update proced
29 matches
Mail list logo