On 11/18/2012 08:00 PM, Zdenek Kabelac wrote:
> For some reason my machine went ouf of memory and OOM killed
> firefox and then even whole Xsession.
>
> Unsure whether it's related to those 2 patches - but I've never had
> such OOM failure before.
As I wrote, this would be me:
Dne 12.11.2012 14:31, Mel Gorman napsal(a):
On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote:
Dne 12.11.2012 13:19, Mel Gorman napsal(a):
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
Dne 12.11.2012 14:31, Mel Gorman napsal(a):
On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote:
Dne 12.11.2012 13:19, Mel Gorman napsal(a):
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
On 11/18/2012 08:00 PM, Zdenek Kabelac wrote:
For some reason my machine went ouf of memory and OOM killed
firefox and then even whole Xsession.
Unsure whether it's related to those 2 patches - but I've never had
such OOM failure before.
As I wrote, this would be me:
Dne 12.11.2012 14:31, Mel Gorman napsal(a):
On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote:
Dne 12.11.2012 13:19, Mel Gorman napsal(a):
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote:
> Dne 12.11.2012 13:19, Mel Gorman napsal(a):
> >On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
> >>Hmm, so it's just took longer to hit the problem and observe kswapd0
> >>spinning on my CPU again - it's not as
Dne 12.11.2012 13:19, Mel Gorman napsal(a):
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
spinning on my CPU again - it's not as endless like before - but
still it easily eats minutes - it helps to turn off
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
> Hmm, so it's just took longer to hit the problem and observe kswapd0
> spinning on my CPU again - it's not as endless like before - but
> still it easily eats minutes - it helps to turn off Firefox or TB
> (memory hungry apps) so
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
spinning on my CPU again - it's not as endless like before - but
still it easily eats minutes - it helps to turn off Firefox or TB
(memory hungry apps) so
Dne 12.11.2012 13:19, Mel Gorman napsal(a):
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
spinning on my CPU again - it's not as endless like before - but
still it easily eats minutes - it helps to turn off
On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote:
Dne 12.11.2012 13:19, Mel Gorman napsal(a):
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
spinning on my CPU again - it's not as endless like
Dne 12.11.2012 14:31, Mel Gorman napsal(a):
On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote:
Dne 12.11.2012 13:19, Mel Gorman napsal(a):
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
Dne 9.11.2012 10:06, Mel Gorman napsal(a):
On Fri, Nov 09, 2012 at 09:07:45AM +0100, Zdenek Kabelac wrote:
fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit
commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c
Author: Rik van Riel
Date: Wed Mar 21 16:33:51 2012 -0700
vmscan:
Dne 9.11.2012 10:06, Mel Gorman napsal(a):
On Fri, Nov 09, 2012 at 09:07:45AM +0100, Zdenek Kabelac wrote:
fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit
commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c
Author: Rik van Riel r...@redhat.com
Date: Wed Mar 21 16:33:51 2012 -0700
On Fri, Nov 09, 2012 at 09:07:45AM +0100, Zdenek Kabelac wrote:
> >fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit
> >commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c
> >Author: Rik van Riel
> >Date: Wed Mar 21 16:33:51 2012 -0700
> >
> > vmscan: reclaim at order 0 when
On Thu, Nov 08, 2012 at 10:22:05PM -0600, Seth Jennings wrote:
> On 11/02/2012 02:45 PM, Jiri Slaby wrote:
> > On 11/02/2012 11:53 AM, Jiri Slaby wrote:
> >> On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
> > Yes, applying this instead of the revert fixes the issue as well.
> >>>
> >>> I've
Dne 9.11.2012 05:22, Seth Jennings napsal(a):
On 11/02/2012 02:45 PM, Jiri Slaby wrote:
On 11/02/2012 11:53 AM, Jiri Slaby wrote:
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on 3.7.0-rc3 kernel - and
Dne 9.11.2012 05:22, Seth Jennings napsal(a):
On 11/02/2012 02:45 PM, Jiri Slaby wrote:
On 11/02/2012 11:53 AM, Jiri Slaby wrote:
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on 3.7.0-rc3 kernel - and
On Thu, Nov 08, 2012 at 10:22:05PM -0600, Seth Jennings wrote:
On 11/02/2012 02:45 PM, Jiri Slaby wrote:
On 11/02/2012 11:53 AM, Jiri Slaby wrote:
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on
On Fri, Nov 09, 2012 at 09:07:45AM +0100, Zdenek Kabelac wrote:
fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit
commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c
Author: Rik van Riel r...@redhat.com
Date: Wed Mar 21 16:33:51 2012 -0700
vmscan: reclaim at order 0 when
On 11/02/2012 02:45 PM, Jiri Slaby wrote:
> On 11/02/2012 11:53 AM, Jiri Slaby wrote:
>> On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
> Yes, applying this instead of the revert fixes the issue as well.
>>>
>>> I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive
>>> CPU
On 11/02/2012 02:45 PM, Jiri Slaby wrote:
On 11/02/2012 11:53 AM, Jiri Slaby wrote:
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive
CPU usage - mainly
On 10/30/2012 03:18 PM, Mel Gorman wrote:
restart:
- wake_all_kswapd(order, zonelist, high_zoneidx,
+ /*
+* kswapd is woken except when this is a THP request and compaction
+* is deferred. If we are backing off reclaim/compaction then kswapd
+* should not
Dne 2.11.2012 20:45, Jiri Slaby napsal(a):
On 11/02/2012 11:53 AM, Jiri Slaby wrote:
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive
CPU usage - mainly
Dne 2.11.2012 20:45, Jiri Slaby napsal(a):
On 11/02/2012 11:53 AM, Jiri Slaby wrote:
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive
CPU usage - mainly
On 10/30/2012 03:18 PM, Mel Gorman wrote:
restart:
- wake_all_kswapd(order, zonelist, high_zoneidx,
+ /*
+* kswapd is woken except when this is a THP request and compaction
+* is deferred. If we are backing off reclaim/compaction then kswapd
+* should not
On 11/02/2012 11:53 AM, Jiri Slaby wrote:
> On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
>>
>> I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive
>> CPU usage - mainly after suspend/resume
>>
>> Here is
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
>>> Yes, applying this instead of the revert fixes the issue as well.
>
> I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive
> CPU usage - mainly after suspend/resume
>
> Here is just simple kswapd backtrace from running
Dne 15.10.2012 13:09, Mel Gorman napsal(a):
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
direct reclaim
Jiri Slaby reported the following:
(It's an
Dne 15.10.2012 13:09, Mel Gorman napsal(a):
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
direct reclaim
Jiri Slaby reported the following:
(It's an
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive
CPU usage - mainly after suspend/resume
Here is just simple kswapd backtrace from running kernel:
Yup,
On 11/02/2012 11:53 AM, Jiri Slaby wrote:
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote:
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive
CPU usage - mainly after suspend/resume
Here is just simple
On Wed, Oct 31, 2012 at 12:25:13PM +0100, Thorsten Leemhuis wrote:
> On 30.10.2012 20:18, Mel Gorman wrote:
> >On Mon, Oct 29, 2012 at 11:52:03AM +0100, Thorsten Leemhuis wrote:
> >>On 15.10.2012 13:09, Mel Gorman wrote:
> >>>On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
> On
On 30.10.2012 20:18, Mel Gorman wrote:
On Mon, Oct 29, 2012 at 11:52:03AM +0100, Thorsten Leemhuis wrote:
On 15.10.2012 13:09, Mel Gorman wrote:
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed
On 30.10.2012 20:18, Mel Gorman wrote:
On Mon, Oct 29, 2012 at 11:52:03AM +0100, Thorsten Leemhuis wrote:
On 15.10.2012 13:09, Mel Gorman wrote:
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed
On Wed, Oct 31, 2012 at 12:25:13PM +0100, Thorsten Leemhuis wrote:
On 30.10.2012 20:18, Mel Gorman wrote:
On Mon, Oct 29, 2012 at 11:52:03AM +0100, Thorsten Leemhuis wrote:
On 15.10.2012 13:09, Mel Gorman wrote:
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57
On Mon, Oct 29, 2012 at 11:52:03AM +0100, Thorsten Leemhuis wrote:
> Hi!
>
> On 15.10.2012 13:09, Mel Gorman wrote:
> >On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
> >>On 10/12/2012 03:57 PM, Mel Gorman wrote:
> >>>mm: vmscan: scale number of pages reclaimed by reclaim/compaction
On Mon, Oct 29, 2012 at 11:52:03AM +0100, Thorsten Leemhuis wrote:
Hi!
On 15.10.2012 13:09, Mel Gorman wrote:
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
Hi!
On 15.10.2012 13:09, Mel Gorman wrote:
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
direct reclaim
Jiri Slaby reported the following:
> [...]
diff --git
Hi!
On 15.10.2012 13:09, Mel Gorman wrote:
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
direct reclaim
Jiri Slaby reported the following:
[...]
diff --git
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
> On 10/12/2012 03:57 PM, Mel Gorman wrote:
> > mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
> > direct reclaim
> >
> > Jiri Slaby reported the following:
> >
> > (It's an effective revert of "mm:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
> mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
> direct reclaim
>
> Jiri Slaby reported the following:
>
> (It's an effective revert of "mm: vmscan: scale number of pages
> reclaimed by reclaim/compaction based
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
direct reclaim
Jiri Slaby reported the following:
(It's an effective revert of mm: vmscan: scale number of pages
reclaimed by reclaim/compaction based on
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
direct reclaim
Jiri Slaby reported the following:
(It's an effective revert of mm: vmscan: scale
On Fri, Oct 12, 2012 at 02:37:58PM +0200, Jiri Slaby wrote:
> On 10/12/2012 12:08 AM, Jiri Slaby wrote:
> > (It's an effective revert of "mm: vmscan: scale number of pages
> > reclaimed by reclaim/compaction based on failures".)
>
> Given kswapd had hours of runtime in ps/top output yesterday in
On 10/12/2012 12:08 AM, Jiri Slaby wrote:
> (It's an effective revert of "mm: vmscan: scale number of pages
> reclaimed by reclaim/compaction based on failures".)
Given kswapd had hours of runtime in ps/top output yesterday in the
morning and after the revert it's now 2 minutes in sum for the
On 10/12/2012 12:08 AM, Jiri Slaby wrote:
(It's an effective revert of mm: vmscan: scale number of pages
reclaimed by reclaim/compaction based on failures.)
Given kswapd had hours of runtime in ps/top output yesterday in the
morning and after the revert it's now 2 minutes in sum for the last
On Fri, Oct 12, 2012 at 02:37:58PM +0200, Jiri Slaby wrote:
On 10/12/2012 12:08 AM, Jiri Slaby wrote:
(It's an effective revert of mm: vmscan: scale number of pages
reclaimed by reclaim/compaction based on failures.)
Given kswapd had hours of runtime in ps/top output yesterday in the
On 10/11/2012 08:19 PM, valdis.kletni...@vt.edu wrote:
> # zgrep COMPAC /proc/config.gz
> CONFIG_COMPACTION=y
>
> Hope that tells you something useful.
It just supports my another theory. This seems to fix it for me:
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1830,8 +1830,8 @@ static inline bool
On 10/11/2012 08:19 PM, valdis.kletni...@vt.edu wrote:
# zgrep COMPAC /proc/config.gz
CONFIG_COMPACTION=y
Hope that tells you something useful.
It just supports my another theory. This seems to fix it for me:
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1830,8 +1830,8 @@ static inline bool
50 matches
Mail list logo
