reiserfs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edward Shishkin <edward.shishkin@gmail.com>
To: Metztli Information Technology
	<jose@huitzilopochtli.metztli-it.com>,
	b747xx@gmail.com, reiserfs-devel@vger.kernel.org
Subject: Re: reiser4[StorageManager(2383)]: lzo1_alloc
Date: Mon, 28 Aug 2017 15:15:34 +0200	[thread overview]
Message-ID: <6ae2ae7d-a83e-33de-d0b7-1b3cfe3cc726@gmail.com> (raw)
In-Reply-To: <20170826071542.2E2333BC3E6@huitzilopochtli.metztli-it.com>

[-- Attachment #1: Type: text/plain, Size: 12935 bytes --]

Please, try the attached patch,
it allows to proceed flushing even workspace allocation was failed.

Thanks,
Edward.

On 08/26/2017 09:15 AM, Metztli Information Technology wrote:
> On Fri, Aug 25, 2017 at 9:22 AM, Edward Shishkin <edward.shishkin@gmail.com> wrote:
>> As a possible fixup we can leave data uncompressed.
>> I think it is rather rare event (the flood of warnings is because
>> of inability to allocate workspace for the same chunk of data.
> If left unfixed in subsequent reiser4 kernel patches, (unseen) stream of 'flood of warnings' has the potential to crash the kernel.
>
>> Edward.
>>
>> On 08/25/2017 06:49 AM, Mathieu Bélanger wrote:
>>> I did have that bug specifically with Chromium too, I did initial try to
>>> test by disabling ALSR (I was suspecting the Ryzen silicon bug that finally
>>> can be RMA).
>>> But disabling ALSR caused more problem so ...
>>>
>>> I did "fix" the issue by recompiling Chromium with -O2 instead of -O3.
>>>
>>> And I do have similar problem with Firefox 57 compiled with -O3 (Again -O2
>>> fix it and Firefox 55 with -O3 is not affected)
> Thing is pre-built Firefox from Debian repositories did not produce warnings -- as far as random captured 2,000 chunks of dmesg output log showed -- only Chromium did.
>>> On Thu, Aug 24, 2017 at 11:42 PM, Metztli Information Technology
>>> <jose@huitzilopochtli.metztli-it.com
>>> <mailto:jose@huitzilopochtli.metztli-it.com>> wrote:
>>>
>>>
>>>
>>>      On Thu, Aug 24, 2017 at 6:01 AM, Edward Shishkin
>>>      <edward.shishkin@gmail.com <mailto:edward.shishkin@gmail.com>> wrote:
>>>      > So, memory allocation policy got changed in the upstream,
>>>      > and we need to perform pre-allocation to not fail at flush time.
>>>      > I am sorry, but right now I don't have a time for this..
>>>      No worries, sir. I simply fulfilled your request for feedback.
>>>
>>>      Background for this test was to evaluate 2TB maximum slice allowed
>>>      by Google Compute Engine in cloud instances, specifically Debian
>>>      with transparent compression reiser4.
>>>
>>>      Currently, (default) transparent compression reiser4 formatting is
>>>      not available[1] in my custom Debian-Installer (d-i) but planned
>>>      to make available in a future implementation.
>>>
>>>      >
>>>      >
>>>      > On 08/24/2017 06:59 AM, Metztli Information Technology wrote:
>>>      >>
>>>      >> Much appreciated, Ed-
>>>      >>
>>>      >> Noticed improvement, notwithstanding...
>>>      >>
>>>      >> Context:
>>>      >>
>>>      >> uname -a
>>>      >> Linux huitzilopochtli 4.12.0-1+reiser4.0.1-amd64 #1 SMP Debian
>>>      >> 4.12.6-3+reiser4.0.1 (2017-08-14) x86_64 GNU/Linux
>>>      >>
>>>      >> (I have reinstalled same kernel two times after patching so the
>>>      above
>>>      >> string retained the older original kernel installation date.
>>>      >> but
>>>      >> uname -v
>>>      >> #1 SMP Debian 4.12.6-3...[means upgrade '-3' reflects fact that
>>>      I rebuilt
>>>      >> fs with your latest two(2) patches to address the issue.])
>>>      >>
>>>      >>
>>>      >>   ls -ltc /lib/modules/4.12.0-1*64/kernel
>>>      >> total 18
>>>      >> drwxr-xr-x 14 root root 16 Aug 23 02:14 sound/
>>>      >> drwxr-xr-x  5 root root 24 Aug 23 02:13 lib/
>>>      >> drwxr-xr-x  2 root root  4 Aug 23 02:13 mm/
>>>      >> drwxr-xr-x 60 root root 62 Aug 23 02:13 fs/
>>>      >> drwxr-xr-x  3 root root 73 Aug 23 02:13 crypto/
>>>      >> drwxr-xr-x  2 root root  4 Aug 23 02:13 block/alloc workspace
>>>
>>>      >> drwxr-xr-x 51 root root 51 Aug 18 17:02 net/
>>>      >> drwxr-xr-x  3 root root  3 Aug 18 17:02 virt/
>>>      >> drwxr-xr-x 70 root root 70 Aug 18 17:02 drivers/
>>>      >> drwxr-xr-x  3 root root  3 Aug 18 17:02 arch/
>>>      >>
>>>      >> After applying (fs/) patches and rebooting, I began to apply
>>>      load to the
>>>      >> machine where with previous kernel I had already built
>>>      GCC-5-branch and
>>>      >> Apache OpenOffice. Memory is limited to 16Gb RAM; copy
>>>      operations were
>>>      >> started from 1TB USB disk to local reiser4 transparent
>>>      compression, a  16Gb
>>>      >> data copy to same local filesystem, began a 2Gb svn download,
>>>      etc.; I had
>>>      >> Firefox open with several tabs open and launched chromium
>>>      browser -- which
>>>      >> began producing relevant feedback. I have set a two(2) thousand
>>>      lines limit
>>>      >> output in my shell so that is the reason *all* of the below
>>>      WARNINGS repeat
>>>      >> that number of times.
>>>      >>
>>>      >> Chromium browser launched but app did not open in the GUI and
>>>      got stuck
>>>      >> with un-killable processes (memory starvation?):
>>>      >>
>>>      >> % kill -9 $(pgrep chromium)
>>>      >> % pgrep chromium
>>>      >> 6320
>>>      >> 6743
>>>      >> 6814
>>>      >> 7050
>>>      >>
>>>      >> Subsequently dmesg showed (<process number>) none necessarily
>>>      in the order
>>>      >> below as dmesg alternated in producing sequence:
>>>      >>
>>>      >> [ 6175.145234] reiser4[chromium(7050)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 6175.145248] reiser4[chromium(7050)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 6175.145261] reiser4[chromium(7050)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 6175.145275] reiser4[chromium(7050)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> (snip)
>>>      >>
>>>      >> [ 7116.052780] reiser4[TaskSchedulerBa(6793)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7116.053021] reiser4[TaskSchedulerBa(6793)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7116.053044] reiser4[TaskSchedulerBa(6793)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7116.055925] reiser4[TaskSchedulerBa(6793)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> (snip)
> It is not only Chromium, as 'TaskSchedulerBa...' aggregated to the warning stream. Accordingly, application(s) generating the warning may vary.  It just happened that I decided to launch Chromium in this particular instance for elaboration.
>
>>>      >>
>>>      >> [ 7309.117294] reiser4[Chrome_DBThread(6796)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7309.117305] reiser4[Chrome_DBThread(6796)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7309.117316] reiser4[Chrome_DBThread(6796)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7309.117327] reiser4[Chrome_DBThread(6796)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7309.117338] reiser4[Chrome_DBThread(6796)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> (snip)
>>>      >>
>>>      >> [ 7550.849425] reiser4[Chrome_HistoryT(6828)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7550.849436] reiser4[Chrome_HistoryT(6828)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7550.849446] reiser4[Chrome_HistoryT(6828)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >>
>>>      >> [ 7550.849457] reiser4[Chrome_HistoryT(6828)]: lzo1_alloc
>>>      >>
>>>     
>>> (/usr/src/build/kernel/build/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>                 WARNING: alloc workspace for lzo1 (tfm action =
>>>      1) failed
>>>      >> (snip)
>>>      >>
>>>      >>
>>>      >> On Tue, Aug 22, 2017 at 11:49 AM, Edward Shishkin
>>>      >> <edward.shishkin@gmail.com <mailto:edward.shishkin@gmail.com>>
>>>
>>>      wrote:
>>>      >>>
>>>      >>> Hello,
>>>      >>>
>>>      >>> Please, try the attached patches.
>>>      >>> The first patch improves responsiveness to vm subsystem
>>>      >>> (modified version of ->migratepage() from Ivan Shapovalov).
>>>      >>> The second patch performs memory allocation in the critical
>>>      >>> place with __GFP_NOFAIL flag.
>>>      >>> Let us know about results.
>>>      >>>
>>>      >>> Thanks,
>>>      >>> Edward.
>>>      >>
>>>      >> []
>>>      >>>>
>>>      >>>> Your input would be greatly appreciated:
>>>      >>>>
>>>      >>>> [ 3449.944653] reiser4[StorageManager(2383)]: lzo1_alloc
>>>      >>>>
>>>      >>>>
>>>     
>>> (/mnt/chiucuetetl/usr/src/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>>>                  WARNING: alloc workspace for lzo1 (tfm
>>>      action = 1)
>>>      >>>> failed
>>>      >>>>
>>>      >>>> [ 3449.944674] reiser4[StorageManager(2383)]: lzo1_alloc
>>>      >>>>
>>>      >>>>
>>>     
>>> (/mnt/chiucuetetl/usr/src/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>>>                  WARNING: alloc workspace for lzo1 (tfm
>>>      action = 1)
>>>      >>>> failed
>>>      >>>>
>>>      >>>> [ 3449.944694] reiser4[StorageManager(2383)]: lzo1_alloc
>>>      >>>>
>>>      >>>>
>>>     
>>> (/mnt/chiucuetetl/usr/src/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>>>                  WARNING: alloc workspace for lzo1 (tfm
>>>      action = 1)
>>>      >>>> failed
>>>      >>>>
>>>      >>>> [ 3449.944715] reiser4[StorageManager(2383)]: lzo1_alloc
>>>      >>>>
>>>      >>>>
>>>     
>>> (/mnt/chiucuetetl/usr/src/linux/fs/reiser4/plugin/compress/compress.c:241)[edward-878]:
>>>      >>>>                  WARNING: alloc workspace for lzo1 (tfm
>>>      action = 1)
>>>      >>>> failed
>>>      >>>>
>>>      >>>> [snip]
>>>      >>
>>>      >> This time dmesg did not output any references to
>>>      [StorageManager(<pid>)]
>>>      >>
>>>      >>
>>>      [1] but default reiser4 formatting can be performed from the
>>>      command line in another virtual terminal.
>>>
> In other developments, I am engaged in a GRUB2 hack quest which, if successful, has the potential to add native reiser4 boot detection to GRUB2; that way, a separate ext2 /boot partition will not be required.
>
>
> Best Professional Regards.
>


[-- Attachment #2: reiser4-dont-prealloc-workspace-for-compression.patch --]
[-- Type: text/x-patch, Size: 2540 bytes --]

diff --git a/plugin/compress/compress.c b/plugin/compress/compress.c
index a574933..2a263ea 100644
--- a/plugin/compress/compress.c
+++ b/plugin/compress/compress.c
@@ -80,15 +80,10 @@ static coa_t gzip1_alloc(tfm_action act)
 		}
 		break;
 	default:
-		impossible("edward-767",
-			   "trying to alloc workspace for unknown tfm action");
+		impossible("edward-767", "unknown tfm action");
 	}
-	if (ret) {
-		warning("edward-768",
-			"alloc workspace for gzip1 (tfm action = %d) failed\n",
-			act);
+	if (ret)
 		return ERR_PTR(ret);
-	}
 	return coa;
 }
 
@@ -232,15 +227,10 @@ static coa_t lzo1_alloc(tfm_action act)
 	case TFMA_READ:		/* decompress */
 		break;
 	default:
-		impossible("edward-877",
-			   "trying to alloc workspace for unknown tfm action");
+		impossible("edward-877", "unknown tfm action");
 	}
-	if (ret) {
-		warning("edward-878",
-			"alloc workspace for lzo1 (tfm action = %d) failed\n",
-			act);
+	if (ret)
 		return ERR_PTR(ret);
-	}
 	return coa;
 }
 
diff --git a/plugin/file/cryptcompress.c b/plugin/file/cryptcompress.c
index e1a3449..694680b 100644
--- a/plugin/file/cryptcompress.c
+++ b/plugin/file/cryptcompress.c
@@ -1103,12 +1103,12 @@ int reiser4_deflate_cluster(struct cluster_handle * clust, struct inode * inode)
 		assert("edward-1423", coplug->compress != NULL);
 
 		result = grab_coa(tc, coplug);
-		if (result) {
-		    warning("edward-1424",
-			    "alloc_coa failed with ret=%d, skipped compression",
-			    result);
-		    goto cipher;
-		}
+		if (result)
+			/*
+			 * can not allocate memory to perform
+			 * compression, leave data uncompressed
+			 */
+			goto cipher;
 		result = grab_tfm_stream(inode, tc, OUTPUT_STREAM);
 		if (result) {
 		    warning("edward-1425",
diff --git a/plugin/item/ctail.c b/plugin/item/ctail.c
index 3f46c38..dc1aa9d 100644
--- a/plugin/item/ctail.c
+++ b/plugin/item/ctail.c
@@ -1252,7 +1252,6 @@ static int attach_convert_idata(flush_pos_t * pos, struct inode *inode)
 	struct convert_item_info *info;
 	struct cluster_handle *clust;
 	file_plugin *fplug = inode_file_plugin(inode);
-	compression_plugin *cplug = inode_compression_plugin(inode);
 
 	assert("edward-248", pos != NULL);
 	assert("edward-249", pos->child != NULL);
@@ -1273,9 +1272,7 @@ static int attach_convert_idata(flush_pos_t * pos, struct inode *inode)
 		reset_convert_data(pos->sq);
 
 	clust = &pos->sq->clust;
-	ret = grab_coa(&clust->tc, cplug);
-	if (ret)
-		goto err;
+
 	ret = set_cluster_by_page(clust,
 				  jnode_page(pos->child),
 				  MAX_CLUSTER_NRPAGES);

  reply	other threads:[~2017-08-28 13:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-26  7:15 reiser4[StorageManager(2383)]: lzo1_alloc Metztli Information Technology
2017-08-28 13:15 ` Edward Shishkin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-08-25  4:42 Metztli Information Technology
     [not found] ` <CAMDqdwxyR7nFy66chkkfVCRVHKA_PHoTosMrynXvvRRiDB-q7Q@mail.gmail.com>
2017-08-25 16:22   ` Edward Shishkin
2017-08-24  4:59 Metztli Information Technology
2017-08-24 13:01 ` Edward Shishkin
2017-08-20 17:15 Metztli Information Technology
2017-08-22 18:49 ` Edward Shishkin
2017-08-30  9:29   ` Edward Shishkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6ae2ae7d-a83e-33de-d0b7-1b3cfe3cc726@gmail.com \
    --to=edward.shishkin@gmail.com \
    --cc=b747xx@gmail.com \
    --cc=jose@huitzilopochtli.metztli-it.com \
    --cc=reiserfs-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).