On 11.12.2012 01:19, Zlatko Calusic wrote:
On 10.12.2012 20:13, Linus Torvalds wrote:
It's worth giving this as much testing as is at all possible, but at
the same time I really don't think I can delay 3.7 any more without
messing up the holiday season too much. So unless something obvious
pops
On 11.12.2012 01:19, Zlatko Calusic wrote:
I will now make one last attempt, I've just reverted 2 Johannes' commits
that were also applied in attempt to fix breakage that removing
gfp_no_kswapd introduced, namely ed23ec4 & c702418. For various reasons
the results of this test will be available t
On Mon, 10 Dec 2012, Linus Torvalds wrote:
> [ Adding High Dickins because of the shmem oops. ]
I had already noticed, and was about to reply; but only then refreshed
my mbox window, to find that you've already done it all for me: thanks.
>
> On Mon, Dec 10, 2012 at 12:35 PM, Zlatko Calusic
> w
On 10.12.2012 22:54, Borislav Petkov wrote:
On Mon, Dec 10, 2012 at 01:47:23PM -0800, Linus Torvalds wrote:
On Mon, Dec 10, 2012 at 1:42 PM, Borislav Petkov wrote:
Aren't we gonna consider the out-of-tree vbox modules being loaded and
causing some corruptions like maybe the single-bit error a
On Mon, Dec 10, 2012 at 01:47:23PM -0800, Linus Torvalds wrote:
> On Mon, Dec 10, 2012 at 1:42 PM, Borislav Petkov wrote:
> >
> > Aren't we gonna consider the out-of-tree vbox modules being loaded and
> > causing some corruptions like maybe the single-bit error above?
> >
> > I'm also thinking of
On Mon, Dec 10, 2012 at 1:42 PM, Borislav Petkov wrote:
>
> Aren't we gonna consider the out-of-tree vbox modules being loaded and
> causing some corruptions like maybe the single-bit error above?
>
> I'm also thinking of this here: https://lkml.org/lkml/2011/10/6/317
Yup, that looks more likely,
On Mon, Dec 10, 2012 at 01:28:54PM -0800, Linus Torvalds wrote:
> [ Adding High Dickins because of the shmem oops. ]
>
> On Mon, Dec 10, 2012 at 12:35 PM, Zlatko Calusic
> wrote:
> >
> > And funny thing that you mention i915, because yesterday my daughter
> > managed to lock up our laptop hard (
[ Adding High Dickins because of the shmem oops. ]
On Mon, Dec 10, 2012 at 12:35 PM, Zlatko Calusic
wrote:
>
> And funny thing that you mention i915, because yesterday my daughter managed
> to lock up our laptop hard (that was a first), and this is what I found in
> kern.log after restart:
>
>
On 10.12.2012 20:13, Linus Torvalds wrote:
>
> It's worth giving this as much testing as is at all possible, but at
> the same time I really don't think I can delay 3.7 any more without
> messing up the holiday season too much. So unless something obvious
> pops up, I will do the release tonight.
On Mon, Dec 10, 2012 at 10:33 AM, Zlatko Calusic
wrote:
>
> I was about to apply the patch that you sent, and reboot the server, but it
> seems there's no point because the patch is flawed?
>
> Anyway, if and when you have a proper one, I'll be glad to test it for you
> and report results.
I have
On 10.12.2012 19:01, Mel Gorman wrote:
In this last-minute disaster, I'm not thinking properly at all any more. The
shrink slab disabling should have happened before the loop_again but even
then it's wrong because it's just covering over the problem.
The way order and testorder interact with how
On 10.12.2012 12:03, Mel Gorman wrote:
There is a big difference between a direct reclaim/compaction for THP
and kswapd doing the same work. Direct reclaim/compaction will try once,
give up quickly and defer requests in the near future to avoid impacting
the system heavily for THP. The same appli
On Mon, Dec 10, 2012 at 11:39:04AM -0500, Johannes Weiner wrote:
> On Mon, Dec 10, 2012 at 11:03:37AM +, Mel Gorman wrote:
> > On Sat, Dec 08, 2012 at 05:01:42PM -0800, Linus Torvalds wrote:
> > > On Sat, 8 Dec 2012, Zlatko Calusic wrote:
> > > > Or sooner... in short: nothing's changed!
> > >
On Mon, Dec 10, 2012 at 11:03:37AM +, Mel Gorman wrote:
> On Sat, Dec 08, 2012 at 05:01:42PM -0800, Linus Torvalds wrote:
> > On Sat, 8 Dec 2012, Zlatko Calusic wrote:
> > > Or sooner... in short: nothing's changed!
> > >
> > > On a 4GB RAM system, where applications use close to 2GB, kswapd l
On Sat, Dec 08, 2012 at 05:01:42PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 8 Dec 2012, Zlatko Calusic wrote:
> >
> > Or sooner... in short: nothing's changed!
> >
> > On a 4GB RAM system, where applications use close to 2GB, kswapd likes to
> > keep
> > around 1GB free (unused), leaving onl
Dne 9.12.2012 02:01, Linus Torvalds napsal(a):
On Sat, 8 Dec 2012, Zlatko Calusic wrote:
Or sooner... in short: nothing's changed!
On a 4GB RAM system, where applications use close to 2GB, kswapd likes to keep
around 1GB free (unused), leaving only 1GB for page/buffer cache. If I force
bigge
On Sat, 8 Dec 2012, Zlatko Calusic wrote:
>
> Or sooner... in short: nothing's changed!
>
> On a 4GB RAM system, where applications use close to 2GB, kswapd likes to keep
> around 1GB free (unused), leaving only 1GB for page/buffer cache. If I force
> bigger page cache by reading a big file and
On 08.12.2012 13:06, Zlatko Calusic wrote:
On 06.12.2012 20:31, Linus Torvalds wrote:
Ok, people seem to be reporting success.
I've applied Johannes' last patch with the new tested-by tags.
I've been testing this patch since it was applied, and it certainly
fixes the kswapd craziness issue,
On 06.12.2012 20:31, Linus Torvalds wrote:
Ok, people seem to be reporting success.
I've applied Johannes' last patch with the new tested-by tags.
I've been testing this patch since it was applied, and it certainly
fixes the kswapd craziness issue, good work Johannes!
But, it's still not p
On 12/04/2012 05:11 PM, Johannes Weiner wrote:
> On Tue, Dec 04, 2012 at 10:15:09AM +0100, Jiri Slaby wrote:
>> It does not apply to -next :/. Should I try anything else?
>
> The COMPACTION_BUILD changed to IS_ENABLED(CONFIG_COMPACTION), below
> is a -next patch. I hope you don't run into other p
On 12/06/2012 03:23 PM, Johannes Weiner wrote:
From: Johannes Weiner
Subject: [patch] mm: vmscan: fix inappropriate zone congestion clearing
c702418 ("mm: vmscan: do not keep kswapd looping forever due to
individual uncompactable zones") removed zone watermark checks from
the compaction code i
On Thu, Dec 06, 2012 at 11:31:21AM -0800, Linus Torvalds wrote:
> Ok, people seem to be reporting success.
>
> I've applied Johannes' last patch with the new tested-by tags.
>
> Johannes (or anybody else, for that matter), please holler LOUDLY if
> you disagreed.. (or if I used the wrong version
On 12/06/2012 02:31 PM, Linus Torvalds wrote:
Ok, people seem to be reporting success.
I've applied Johannes' last patch with the new tested-by tags.
Johannes (or anybody else, for that matter), please holler LOUDLY if
you disagreed.. (or if I used the wrong version of the patch, there's
been s
Ok, people seem to be reporting success.
I've applied Johannes' last patch with the new tested-by tags.
Johannes (or anybody else, for that matter), please holler LOUDLY if
you disagreed.. (or if I used the wrong version of the patch, there's
been several, afaik).
Linus
--
To un
On Tue, Dec 04, 2012 at 21:01:33 -0600,
Bruno Wolff III wrote:
On Tue, Dec 04, 2012 at 16:42:10 -0500,
Johannes Weiner wrote:
kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.i686
and
kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.x86_64
for over 24hours with no evidence of prob
Dne 4.12.2012 10:05, Zdenek Kabelac napsal(a):
Dne 3.12.2012 20:18, Johannes Weiner napsal(a):
Szia Zdenek,
On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote:
Ok, bad news - I've been hit by kswapd0 loop again -
my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again
Hi!
Just a quick update
Johannes Weiner wrote on 03.12.2012 20:42:
> On Mon, Dec 03, 2012 at 09:30:12AM +0100, Thorsten Leemhuis wrote:
>
>> BTW, I built that kernel without the patch you mentioned in
>> http://thread.gmane.org/gmane.linux.kernel.mm/90911/focus=91153
>> ("buffer_heads_over_limit
On Tue, Dec 04, 2012 at 16:42:10 -0500,
Johannes Weiner wrote:
kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.i686
and
kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.x86_64
for over 24hours with no evidence of problems with kswapd"
Now waiting for results from Jiri, Zdenek and
On Mon, Dec 03, 2012 at 02:42:08PM -0500, Johannes Weiner wrote:
> On Mon, Dec 03, 2012 at 09:30:12AM +0100, Thorsten Leemhuis wrote:
> > >> John was able to reproduce the problem quickly with a kernel that
> > >> contained the patch from your mail. For details see
> > >
> > > [stripped: all the g
On Tue, Dec 04, 2012 at 05:22:38PM +0100, Jiri Slaby wrote:
> On 12/04/2012 05:11 PM, Johannes Weiner wrote:
> Any chance you could retry with this patch on top?
> >>
> >> It does not apply to -next :/. Should I try anything else?
> >
> > The COMPACTION_BUILD changed to IS_ENABLED(CONFIG_COMP
On 12/04/2012 05:11 PM, Johannes Weiner wrote:
Any chance you could retry with this patch on top?
>>
>> It does not apply to -next :/. Should I try anything else?
>
> The COMPACTION_BUILD changed to IS_ENABLED(CONFIG_COMPACTION), below
> is a -next patch. I hope you don't run into other prob
On Tue, Dec 04, 2012 at 10:05:29AM +0100, Zdenek Kabelac wrote:
> Dne 3.12.2012 20:18, Johannes Weiner napsal(a):
> >Szia Zdenek,
> >
> >On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote:
> >>Ok, bad news - I've been hit by kswapd0 loop again -
> >>my kernel git commit cc19528bd3084c3
On Tue, Dec 04, 2012 at 10:15:09AM +0100, Jiri Slaby wrote:
> On 12/04/2012 10:05 AM, Zdenek Kabelac wrote:
> > Dne 3.12.2012 20:18, Johannes Weiner napsal(a):
> >> Szia Zdenek,
> >>
> >> On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote:
> >>> Ok, bad news - I've been hit by kswapd0
On 12/04/2012 10:05 AM, Zdenek Kabelac wrote:
> Dne 3.12.2012 20:18, Johannes Weiner napsal(a):
>> Szia Zdenek,
>>
>> On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote:
>>> Ok, bad news - I've been hit by kswapd0 loop again -
>>> my kernel git commit cc19528bd3084c3c2d870b31a3578da8c6
Dne 3.12.2012 20:18, Johannes Weiner napsal(a):
Szia Zdenek,
On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote:
Ok, bad news - I've been hit by kswapd0 loop again -
my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again
shown kswapd0 for couple minutes on CPU.
It see
On 12/03/2012 02:14 PM, Jiri Slaby wrote:
> On 11/27/2012 09:48 PM, Johannes Weiner wrote:
>> I hope I included everybody that participated in the various threads
>> on kswapd getting stuck / exhibiting high CPU usage. We were looking
>> at at least three root causes as far as I can see, so it's n
On Mon, Dec 03, 2012 at 09:30:12AM +0100, Thorsten Leemhuis wrote:
> >> John was able to reproduce the problem quickly with a kernel that
> >> contained the patch from your mail. For details see
> >
> > [stripped: all the glory details of what likely went wrong and lead
> > to the problem john see
Szia Zdenek,
On Mon, Dec 03, 2012 at 04:23:15PM +0100, Zdenek Kabelac wrote:
> Ok, bad news - I've been hit by kswapd0 loop again -
> my kernel git commit cc19528bd3084c3c2d870b31a3578da8c69952f3 again
> shown kswapd0 for couple minutes on CPU.
>
> It seemed to go instantly away when I've drop c
Dne 28.11.2012 10:45, Mel Gorman napsal(a):
(Adding Thorsten to cc)
On Tue, Nov 27, 2012 at 03:48:34PM -0500, Johannes Weiner wrote:
Hi everyone,
I hope I included everybody that participated in the various threads
on kswapd getting stuck / exhibiting high CPU usage. We were looking
at at lea
On 11/27/2012 09:48 PM, Johannes Weiner wrote:
> I hope I included everybody that participated in the various threads
> on kswapd getting stuck / exhibiting high CPU usage. We were looking
> at at least three root causes as far as I can see, so it's not really
> clear who observed which problem.
On Mon, Dec 03, 2012 at 09:30:12AM +0100, Thorsten Leemhuis wrote:
> Np; BTW, in case anybody here on LKML cares: I started maintaining a
> side repo (PPA in ubuntu speak) a few weeks ago that offers kernel
> vanilla builds (mainline and stable) for the Fedora 17 and 18; see
> https://fedoraproject
Hi!
Johannes Weiner wrote on 01.12.2012 01:45:
> On Fri, Nov 30, 2012 at 01:39:03PM +0100, Thorsten Leemhuis wrote:
>> /me wonders how to elegantly get out of his man-in-the-middle position
> You control the mighty koji :-)
Something even a journalist can ;-)
> But seriously, this is very helpfu
Hi Thorsten,
On Fri, Nov 30, 2012 at 01:39:03PM +0100, Thorsten Leemhuis wrote:
> /me wonders how to elegantly get out of his man-in-the-middle position
You control the mighty koji :-)
But seriously, this is very helpful, thank you! John now also Cc'd
directly.
> John was able to reproduce the
Johannes Weiner wrote on 29.11.2012 18:05:
> On Thu, Nov 29, 2012 at 04:30:12PM +0100, Thorsten Leemhuis wrote:
>> Mel Gorman wrote on 29.11.2012 00:54:
>> > On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
>> >> On Wed, 28 Nov 2012 10:13:59 +
>> >> Mel Gorman wrote:
>> >> > Base
On Thu, Nov 29, 2012 at 04:30:12PM +0100, Thorsten Leemhuis wrote:
> Mel Gorman wrote on 29.11.2012 00:54:
> > On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
> >> On Wed, 28 Nov 2012 10:13:59 +
> >> Mel Gorman wrote:
> >>
> >> > Based on the reports I've seen I expect the foll
Mel Gorman wrote on 29.11.2012 00:54:
> On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
>> On Wed, 28 Nov 2012 10:13:59 +
>> Mel Gorman wrote:
>>
>> > Based on the reports I've seen I expect the following to work for 3.7
>> > Keep
>> > 96710098 mm: revert "mm: vmscan: scale n
On Wed, 28 Nov 2012 23:54:12 +
Mel Gorman wrote:
> On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
> > On Wed, 28 Nov 2012 10:13:59 +
> > Mel Gorman wrote:
> >
> > > Based on the reports I've seen I expect the following to work for 3.7
> > >
> > > Keep
> > > 96710098 m
On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
> On Wed, 28 Nov 2012 10:13:59 +
> Mel Gorman wrote:
>
> > Based on the reports I've seen I expect the following to work for 3.7
> >
> > Keep
> > 96710098 mm: revert "mm: vmscan: scale number of pages reclaimed by
> > reclaim/
On Wed, 28 Nov 2012 10:13:59 +
Mel Gorman wrote:
> Based on the reports I've seen I expect the following to work for 3.7
>
> Keep
> 96710098 mm: revert "mm: vmscan: scale number of pages reclaimed by
> reclaim/compaction based on failures"
> ef6c5be6 fix incorrect NR_FREE_PAGES accounti
On Wed, Nov 28, 2012 at 10:13:59AM +, Mel Gorman wrote:
> On Tue, Nov 27, 2012 at 03:19:38PM -0800, Linus Torvalds wrote:
> > On Tue, Nov 27, 2012 at 2:26 PM, Johannes Weiner wrote:
> > > On Tue, Nov 27, 2012 at 05:02:36PM -0500, Rik van Riel wrote:
> > >>
> > >> Kswapd going crazy is certainl
On 11/28/2012 02:35 PM, Zdenek Kabelac wrote:
> and added slightly modified patch from Jiri
> (https://lkml.org/lkml/2012/11/15/950
> (Unsure where it still applies for -rc7??)
It is needed for -next only. And if you have recent -next, it's already
there...
thanks,
--
js
suse labs
--
To unsubscr
Dne 27.11.2012 21:58, Linus Torvalds napsal(a):
Note that in the meantime, I've also applied (through Andrew) the
patch that reverts commit c654345924f7 (see commit 82b212f40059
'Revert "mm: remove __GFP_NO_KSWAPD"').
I wonder if that revert may be bogus, and a result of this same issue.
Maybe t
Mel Gorman wrote on 28.11.2012 11:13:
> On Tue, Nov 27, 2012 at 03:19:38PM -0800, Linus Torvalds wrote:
>> On Tue, Nov 27, 2012 at 2:26 PM, Johannes Weiner wrote:
>> > On Tue, Nov 27, 2012 at 05:02:36PM -0500, Rik van Riel wrote:
>
>> And the one who comes out gets to explain to me which patch(es)
On Tue, Nov 27, 2012 at 03:19:38PM -0800, Linus Torvalds wrote:
> On Tue, Nov 27, 2012 at 2:26 PM, Johannes Weiner wrote:
> > On Tue, Nov 27, 2012 at 05:02:36PM -0500, Rik van Riel wrote:
> >>
> >> Kswapd going crazy is certainly a large part of the problem.
> >>
> >> However, that leaves the issu
(Adding Thorsten to cc)
On Tue, Nov 27, 2012 at 03:48:34PM -0500, Johannes Weiner wrote:
> Hi everyone,
>
> I hope I included everybody that participated in the various threads
> on kswapd getting stuck / exhibiting high CPU usage. We were looking
> at at least three root causes as far as I can
On Tue, Nov 27, 2012 at 2:26 PM, Johannes Weiner wrote:
> On Tue, Nov 27, 2012 at 05:02:36PM -0500, Rik van Riel wrote:
>>
>> Kswapd going crazy is certainly a large part of the problem.
>>
>> However, that leaves the issue of page_alloc.c waking up
>> kswapd when the system is not actually low on
On Tue, Nov 27, 2012 at 05:02:36PM -0500, Rik van Riel wrote:
> On 11/27/2012 04:49 PM, Johannes Weiner wrote:
> >On Tue, Nov 27, 2012 at 04:16:52PM -0500, Rik van Riel wrote:
> >>On 11/27/2012 03:58 PM, Linus Torvalds wrote:
> >>>Note that in the meantime, I've also applied (through Andrew) the
>
On 11/27/2012 04:49 PM, Johannes Weiner wrote:
On Tue, Nov 27, 2012 at 04:16:52PM -0500, Rik van Riel wrote:
On 11/27/2012 03:58 PM, Linus Torvalds wrote:
Note that in the meantime, I've also applied (through Andrew) the
patch that reverts commit c654345924f7 (see commit 82b212f40059
'Revert "m
On Tue, Nov 27, 2012 at 04:16:52PM -0500, Rik van Riel wrote:
> On 11/27/2012 03:58 PM, Linus Torvalds wrote:
> >Note that in the meantime, I've also applied (through Andrew) the
> >patch that reverts commit c654345924f7 (see commit 82b212f40059
> >'Revert "mm: remove __GFP_NO_KSWAPD"').
> >
> >I w
On Tue, Nov 27, 2012 at 12:58:18PM -0800, Linus Torvalds wrote:
> Note that in the meantime, I've also applied (through Andrew) the
> patch that reverts commit c654345924f7 (see commit 82b212f40059
> 'Revert "mm: remove __GFP_NO_KSWAPD"').
>
> I wonder if that revert may be bogus, and a result of
On 11/27/2012 03:58 PM, Linus Torvalds wrote:
Note that in the meantime, I've also applied (through Andrew) the
patch that reverts commit c654345924f7 (see commit 82b212f40059
'Revert "mm: remove __GFP_NO_KSWAPD"').
I wonder if that revert may be bogus, and a result of this same issue.
Maybe tha
Note that in the meantime, I've also applied (through Andrew) the
patch that reverts commit c654345924f7 (see commit 82b212f40059
'Revert "mm: remove __GFP_NO_KSWAPD"').
I wonder if that revert may be bogus, and a result of this same issue.
Maybe that revert should be reverted, and replaced with y
Hi everyone,
I hope I included everybody that participated in the various threads
on kswapd getting stuck / exhibiting high CPU usage. We were looking
at at least three root causes as far as I can see, so it's not really
clear who observed which problem. Please correct me if the
reported-by, tes
63 matches
Mail list logo
