On Mon, Jul 30, 2018 at 08:09:33AM +0200, Tino Lehnig wrote:
> On 07/28/2018 12:58 AM, Minchan Kim wrote:
> > I made a mistake on previous patch.
> > Could you test this patches?
>
> Thanks! Looking good so far! No errors whatsoever with the new patch. I will
> let my test workload running for
On Mon, Jul 30, 2018 at 08:09:33AM +0200, Tino Lehnig wrote:
> On 07/28/2018 12:58 AM, Minchan Kim wrote:
> > I made a mistake on previous patch.
> > Could you test this patches?
>
> Thanks! Looking good so far! No errors whatsoever with the new patch. I will
> let my test workload running for
On 07/28/2018 12:58 AM, Minchan Kim wrote:
I made a mistake on previous patch.
Could you test this patches?
Thanks! Looking good so far! No errors whatsoever with the new patch. I
will let my test workload running for while to be sure, but I think we
are good.
--
Kind regards,
Tino Lehnig
On 07/28/2018 12:58 AM, Minchan Kim wrote:
I made a mistake on previous patch.
Could you test this patches?
Thanks! Looking good so far! No errors whatsoever with the new patch. I
will let my test workload running for while to be sure, but I think we
are good.
--
Kind regards,
Tino Lehnig
On Fri, Jul 27, 2018 at 02:13:57PM +0200, Tino Lehnig wrote:
> On 07/27/2018 02:05 PM, Minchan Kim wrote:
> > And bad page is always with writeback enable?
> >
> > writeback enable means "echo "some dev" > /sys/block/zram0/backing_dev,
> > not just enable CONFIG_ZRAM_WRITEBACK.
>
> Yes, the bug
On Fri, Jul 27, 2018 at 02:13:57PM +0200, Tino Lehnig wrote:
> On 07/27/2018 02:05 PM, Minchan Kim wrote:
> > And bad page is always with writeback enable?
> >
> > writeback enable means "echo "some dev" > /sys/block/zram0/backing_dev,
> > not just enable CONFIG_ZRAM_WRITEBACK.
>
> Yes, the bug
On 07/27/2018 02:05 PM, Minchan Kim wrote:
And bad page is always with writeback enable?
writeback enable means "echo "some dev" > /sys/block/zram0/backing_dev,
not just enable CONFIG_ZRAM_WRITEBACK.
Yes, the bug only appears when backing_dev is set.
--
Kind regards,
Tino Lehnig
On 07/27/2018 02:05 PM, Minchan Kim wrote:
And bad page is always with writeback enable?
writeback enable means "echo "some dev" > /sys/block/zram0/backing_dev,
not just enable CONFIG_ZRAM_WRITEBACK.
Yes, the bug only appears when backing_dev is set.
--
Kind regards,
Tino Lehnig
On Fri, Jul 27, 2018 at 01:00:01PM +0200, Tino Lehnig wrote:
> On 07/27/2018 11:14 AM, Minchan Kim wrote:
> > I tried to reproduce with KVM but was not successful and I don't have
> > real mahcine to reproduce it. I am asking one device for it.
> >
> > Anyway, I want to try this patch.
> > Could
On Fri, Jul 27, 2018 at 01:00:01PM +0200, Tino Lehnig wrote:
> On 07/27/2018 11:14 AM, Minchan Kim wrote:
> > I tried to reproduce with KVM but was not successful and I don't have
> > real mahcine to reproduce it. I am asking one device for it.
> >
> > Anyway, I want to try this patch.
> > Could
On 07/27/2018 11:14 AM, Minchan Kim wrote:
I tried to reproduce with KVM but was not successful and I don't have
real mahcine to reproduce it. I am asking one device for it.
Anyway, I want to try this patch.
Could you apply attached two patches?
Thanks, I applied the patches on 4.18-rc6, but
On 07/27/2018 11:14 AM, Minchan Kim wrote:
I tried to reproduce with KVM but was not successful and I don't have
real mahcine to reproduce it. I am asking one device for it.
Anyway, I want to try this patch.
Could you apply attached two patches?
Thanks, I applied the patches on 4.18-rc6, but
I tried to reproduce with KVM but was not successful and I don't have
real mahcine to reproduce it. I am asking one device for it.
Anyway, I want to try this patch.
Could you apply attached two patches?
On Thu, Jul 26, 2018 at 02:35:15PM +0200, Tino Lehnig wrote:
> On 07/26/2018 12:30 PM,
I tried to reproduce with KVM but was not successful and I don't have
real mahcine to reproduce it. I am asking one device for it.
Anyway, I want to try this patch.
Could you apply attached two patches?
On Thu, Jul 26, 2018 at 02:35:15PM +0200, Tino Lehnig wrote:
> On 07/26/2018 12:30 PM,
On 07/26/2018 12:30 PM, Minchan Kim wrote:
Huh, you see it without writeback? It's weird. Without writeback feature,
zram operaion is always synchronous on memory compression/decompression
so you shouldn't see below io_schedule logic which happens only for
asynchronous IO operation.
Could you
On 07/26/2018 12:30 PM, Minchan Kim wrote:
Huh, you see it without writeback? It's weird. Without writeback feature,
zram operaion is always synchronous on memory compression/decompression
so you shouldn't see below io_schedule logic which happens only for
asynchronous IO operation.
Could you
On Thu, Jul 26, 2018 at 12:00:44PM +0200, Tino Lehnig wrote:
> On 07/26/2018 08:10 AM, Tino Lehnig wrote:
> > > A thing I could imagine is
> > > [0bcac06f27d75, skip swapcache for swapin of synchronous device]
> > > It was merged into v4.15. Could you check it by bisecting?
> >
> > Thanks, I will
On Thu, Jul 26, 2018 at 12:00:44PM +0200, Tino Lehnig wrote:
> On 07/26/2018 08:10 AM, Tino Lehnig wrote:
> > > A thing I could imagine is
> > > [0bcac06f27d75, skip swapcache for swapin of synchronous device]
> > > It was merged into v4.15. Could you check it by bisecting?
> >
> > Thanks, I will
On 07/26/2018 08:10 AM, Tino Lehnig wrote:
A thing I could imagine is
[0bcac06f27d75, skip swapcache for swapin of synchronous device]
It was merged into v4.15. Could you check it by bisecting?
Thanks, I will check that.
So I get the same behavior as in v4.15-rc1 after this commit. All prior
On 07/26/2018 08:10 AM, Tino Lehnig wrote:
A thing I could imagine is
[0bcac06f27d75, skip swapcache for swapin of synchronous device]
It was merged into v4.15. Could you check it by bisecting?
Thanks, I will check that.
So I get the same behavior as in v4.15-rc1 after this commit. All prior
On 07/26/2018 08:21 AM, Minchan Kim wrote:
That means you could reproduce it without writeback feature?
If so, it would be more reasoanble to check [0bcac06f27d75, skip swapcache for
swapin of synchronous device]
No, the bug only occurs with a backing device. The writeback feature is
enabled
On 07/26/2018 08:21 AM, Minchan Kim wrote:
That means you could reproduce it without writeback feature?
If so, it would be more reasoanble to check [0bcac06f27d75, skip swapcache for
swapin of synchronous device]
No, the bug only occurs with a backing device. The writeback feature is
enabled
On Thu, Jul 26, 2018 at 08:10:41AM +0200, Tino Lehnig wrote:
> Hi,
>
> On 07/26/2018 04:03 AM, Minchan Kim wrote:
> > A thing I could imagine is
> > [0bcac06f27d75, skip swapcache for swapin of synchronous device]
> > It was merged into v4.15. Could you check it by bisecting?
>
> Thanks, I will
On Thu, Jul 26, 2018 at 08:10:41AM +0200, Tino Lehnig wrote:
> Hi,
>
> On 07/26/2018 04:03 AM, Minchan Kim wrote:
> > A thing I could imagine is
> > [0bcac06f27d75, skip swapcache for swapin of synchronous device]
> > It was merged into v4.15. Could you check it by bisecting?
>
> Thanks, I will
Hi,
On 07/26/2018 04:03 AM, Minchan Kim wrote:
A thing I could imagine is
[0bcac06f27d75, skip swapcache for swapin of synchronous device]
It was merged into v4.15. Could you check it by bisecting?
Thanks, I will check that.
My operating system is a minimal install of Debian 9. I took the
Hi,
On 07/26/2018 04:03 AM, Minchan Kim wrote:
A thing I could imagine is
[0bcac06f27d75, skip swapcache for swapin of synchronous device]
It was merged into v4.15. Could you check it by bisecting?
Thanks, I will check that.
My operating system is a minimal install of Debian 9. I took the
Hi Tino,
On Wed, Jul 25, 2018 at 05:12:13PM +0200, Tino Lehnig wrote:
> Hi,
>
> On 07/25/2018 03:21 PM, Minchan Kim wrote:
> > It would be much helpful if you could check more versions with git-bisect.
>
> I started bisecting today, but my results are not conclusive yet. It is
> certain that
Hi Tino,
On Wed, Jul 25, 2018 at 05:12:13PM +0200, Tino Lehnig wrote:
> Hi,
>
> On 07/25/2018 03:21 PM, Minchan Kim wrote:
> > It would be much helpful if you could check more versions with git-bisect.
>
> I started bisecting today, but my results are not conclusive yet. It is
> certain that
Hi,
On 07/25/2018 03:21 PM, Minchan Kim wrote:
It would be much helpful if you could check more versions with git-bisect.
I started bisecting today, but my results are not conclusive yet. It is
certain that the problem started with 4.15 though. I have not
encountered the bug message in
Hi,
On 07/25/2018 03:21 PM, Minchan Kim wrote:
It would be much helpful if you could check more versions with git-bisect.
I started bisecting today, but my results are not conclusive yet. It is
certain that the problem started with 4.15 though. I have not
encountered the bug message in
On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> Hi,
>
> The first build I used was from the master branch of the mainline kernel,
> somewhere between rc5 and rc6. I have just reproduced the bug with 4.17.9
> and 4.18-rc6. Kernel messages below.
>
> The bug does not appear on
On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> Hi,
>
> The first build I used was from the master branch of the mainline kernel,
> somewhere between rc5 and rc6. I have just reproduced the bug with 4.17.9
> and 4.18-rc6. Kernel messages below.
>
> The bug does not appear on
On (07/24/18 19:51), Matthew Wilcox wrote:
>
> Also note that this is in the allocation path; this flag isn't checked
> at free. But it is cleared on free, so someone's stomping on page->flags
> after they're freed. I suggest enabling more debugging code.
Would be lovely if Tino could bisect
On (07/24/18 19:51), Matthew Wilcox wrote:
>
> Also note that this is in the allocation path; this flag isn't checked
> at free. But it is cleared on free, so someone's stomping on page->flags
> after they're freed. I suggest enabling more debugging code.
Would be lovely if Tino could bisect
On Tue, Jul 24, 2018 at 07:55:25PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> > > There is NOTHING in a union with _refcount.
> >
> > Confusing. Matthew, what am I missing?
> >
On Tue, Jul 24, 2018 at 07:55:25PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> > > There is NOTHING in a union with _refcount.
> >
> > Confusing. Matthew, what am I missing?
> >
On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote:
> On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> > There is NOTHING in a union with _refcount.
>
> Confusing. Matthew, what am I missing?
>
> Before:
>
> counters consumes 8 bytes
> units and _refcount consumes each
On Wed, Jul 25, 2018 at 11:51:06AM +0900, Minchan Kim wrote:
> On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> > There is NOTHING in a union with _refcount.
>
> Confusing. Matthew, what am I missing?
>
> Before:
>
> counters consumes 8 bytes
> units and _refcount consumes each
On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > [ 804.485321] BUG: Bad page state in process qemu-system-x86 pfn:1c4b08e
> > [ 804.485403] page:e809312c2380 count:0 mapcount:0
> > mapping: index:0x1
> > [ 804.485483] flags: 0x17fffc8(uptodate)
> > [
On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > [ 804.485321] BUG: Bad page state in process qemu-system-x86 pfn:1c4b08e
> > [ 804.485403] page:e809312c2380 count:0 mapcount:0
> > mapping: index:0x1
> > [ 804.485483] flags: 0x17fffc8(uptodate)
> > [
On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > > Hi Tino,
> > > >
> > > > On
On Tue, Jul 24, 2018 at 07:35:32PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> > On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > > Hi Tino,
> > > >
> > > > On
On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > Hi Tino,
> > >
> > > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > > Hi,
> > >
On Wed, Jul 25, 2018 at 11:16:57AM +0900, Minchan Kim wrote:
> On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> > On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > > Hi Tino,
> > >
> > > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > > Hi,
> > >
On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > Hi Tino,
> >
> > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > Hi,
> > >
> > > The first build I used was from the master branch of the mainline
On Tue, Jul 24, 2018 at 06:55:02PM -0700, Matthew Wilcox wrote:
> On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> > Hi Tino,
> >
> > On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > > Hi,
> > >
> > > The first build I used was from the master branch of the mainline
On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> Hi Tino,
>
> On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > Hi,
> >
> > The first build I used was from the master branch of the mainline kernel,
> > somewhere between rc5 and rc6. I have just reproduced the bug
On Wed, Jul 25, 2018 at 10:32:50AM +0900, Minchan Kim wrote:
> Hi Tino,
>
> On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> > Hi,
> >
> > The first build I used was from the master branch of the mainline kernel,
> > somewhere between rc5 and rc6. I have just reproduced the bug
Hi Tino,
On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> Hi,
>
> The first build I used was from the master branch of the mainline kernel,
> somewhere between rc5 and rc6. I have just reproduced the bug with 4.17.9
> and 4.18-rc6. Kernel messages below.
>
> The bug does not
Hi Tino,
On Tue, Jul 24, 2018 at 09:30:34AM +0200, Tino Lehnig wrote:
> Hi,
>
> The first build I used was from the master branch of the mainline kernel,
> somewhere between rc5 and rc6. I have just reproduced the bug with 4.17.9
> and 4.18-rc6. Kernel messages below.
>
> The bug does not
Hi,
The first build I used was from the master branch of the mainline
kernel, somewhere between rc5 and rc6. I have just reproduced the bug
with 4.17.9 and 4.18-rc6. Kernel messages below.
The bug does not appear on 4.14.57. I can test more versions if it helps.
On 07/24/2018 03:03 AM,
Hi,
The first build I used was from the master branch of the mainline
kernel, somewhere between rc5 and rc6. I have just reproduced the bug
with 4.17.9 and 4.18-rc6. Kernel messages below.
The bug does not appear on 4.14.57. I can test more versions if it helps.
On 07/24/2018 03:03 AM,
On Tue, Jul 24, 2018 at 11:53:30AM +0900, Sergey Senozhatsky wrote:
> On (07/24/18 10:03), Minchan Kim wrote:
> > On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> > > Hello,
> > >
> > > after enabling the writeback feature in zram, I encountered the kernel bug
> > > below with heavy
On Tue, Jul 24, 2018 at 11:53:30AM +0900, Sergey Senozhatsky wrote:
> On (07/24/18 10:03), Minchan Kim wrote:
> > On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> > > Hello,
> > >
> > > after enabling the writeback feature in zram, I encountered the kernel bug
> > > below with heavy
On (07/24/18 10:03), Minchan Kim wrote:
> On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> > Hello,
> >
> > after enabling the writeback feature in zram, I encountered the kernel bug
> > below with heavy swap utilization. There is one specific workload that
> > triggers the bug
On (07/24/18 10:03), Minchan Kim wrote:
> On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> > Hello,
> >
> > after enabling the writeback feature in zram, I encountered the kernel bug
> > below with heavy swap utilization. There is one specific workload that
> > triggers the bug
Hi Tino,
Thanks for the report.
On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> Hello,
>
> after enabling the writeback feature in zram, I encountered the kernel bug
> below with heavy swap utilization. There is one specific workload that
> triggers the bug reliably and that is
Hi Tino,
Thanks for the report.
On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> Hello,
>
> after enabling the writeback feature in zram, I encountered the kernel bug
> below with heavy swap utilization. There is one specific workload that
> triggers the bug reliably and that is
Hello,
after enabling the writeback feature in zram, I encountered the kernel
bug below with heavy swap utilization. There is one specific workload
that triggers the bug reliably and that is running Windows in KVM while
overcommitting memory. The Windows VMs would fill all allocated memory
Hello,
after enabling the writeback feature in zram, I encountered the kernel
bug below with heavy swap utilization. There is one specific workload
that triggers the bug reliably and that is running Windows in KVM while
overcommitting memory. The Windows VMs would fill all allocated memory
60 matches
Mail list logo
