public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Planning out Core Update 117
Date: Tue, 21 Nov 2017 18:35:23 +0100	[thread overview]
Message-ID: <f83a7e53-c735-6ef7-42ac-b9f43e77ffb5@ipfire.org> (raw)
In-Reply-To: <1511275374.4838.600.camel@ipfire.org>

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

Hi,

On 21.11.2017 15:42, Michael Tremer wrote:
> Hello,
> 
> any progress on this?

Not much, because I've been struggling with a flu for the past two
weeks, and its not over yet, but:

In the meantime I ran several builds with different parameters.

IMHO we could use:

'export XZ_OPT = --threads=0 -8 --memory=700MiB'

in 'lfs/cdrom'

and

cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8 --memory=700MiB" tar -c -p --numeric-owner -J -f /install/packages/package/files.tar.xz *

in 'lfs/Config'.

Using '9' or '--extreme'-parameter brought no further improvements,
on the other hand, build time and RAM consumption increased
strongly. With '-8', minimal RAM consumption was about 680 MiB, using
'700 Mib' was always safe. So this is the minimum I would recommend.

Results:

(Buildtime: 5 hours 20 minutes 59 seconds)

255866764  ipfire-2.19.1gb-ext4.i586-full-core117.img.gz
252262006  ipfire-2.19.1gb-ext4-scon.i586-full-core117.img.gz
175112192  ipfire-2.19.i586-full-core117.iso
 
> -Michael
> 
> On Tue, 2017-11-07 at 22:47 +0000, Michael Tremer wrote:
>> Hi,
>> 
>> On Tue, 2017-11-07 at 19:41 +0100, Matthias Fischer wrote:
>> > Hi,
>> > 
>> > On 07.11.2017 16:05, Michael Tremer wrote:
>> > > Hi,
>> > > 
>> > > maybe this function helps:
>> > > 
>> > > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5190eea24f9822a63d
>> > > c5d06d214b48f973b14f29
>> > 
>> > Thanks. I'll take a look...

This would help, indeed, but how to implement(!?), and... (see below)

>> > > On Tue, 2017-11-07 at 10:46 +0000, Michael Tremer wrote:
>> > > > On Mon, 2017-11-06 at 22:09 +0100, Matthias Fischer wrote:
>> > > > ...
>> > > > > 
>> > > > > I forgot: Tuning the XZ-parameters... ;-)
>> > > > 
>> > > > Good that you are bringing this up. So I think what we should do here is
>> > > > bringing back XZ compression with -8 so that we do not waste too much
>> > > > space
>> > > > when
>> > > > extracting the image again.
>> > 
>> > Right now I'm testing how much RAM I need.
>> > 
>> > Current 'next'-build is running with:
>> > 
>> > 'lfs/cdrom':
>> > ...
>> > export XZ_OPT = --threads=0 -8 --memory=500MiB
>> > ...
>> > 
>> > 'lfs/Config':
>> > ...
>> > cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8" ...
>> > ...
>> > 
>> > I'm waiting for the results. Takes a while.
>> 
>> You can just run it like this and it will tell you:
>> 
>> [ms(a)hughes ~]$ xz -vv8 -T0
>> xz: Filter chain: --
>> lzma2=dict=32MiB,lc=3,lp=0,pb=2,mode=normal,nice=64,mf=bt4,depth=0
>> xz: Using up to 4 threads.
>> xz: 2,629 MiB of memory is required. The limiter is disabled.
>> xz: Decompression will need 33 MiB of memory.
>> xz: Compressed data cannot be written to a terminal
>> xz: Try `xz --help' for more information.
>> 
>> > > > To not run into memory limits we should detect how much memory the build
>> > > > host
>> > > > has and set the memory limit to maybe 80% of that. xz will then
>> > > > automatically
>> > > > scale down to a number of parallel processes that it can fit into
>> > > > memory.

This is something I couldn't get to work. First, I couldn't specify not less
than '700 MiB'. If I specify '600 MiB', building stops and tells me it needs
at least about 680 MiB. If I use '70%', building stops. And I never saw that
'xz' "automatically scaled down". It just stopped everytime.
 
>> > I'm a bit puzzled about this: I tried using '--memory=70%' as mentioned
>> > in the xz man pages, but is seems to have no effect. It looks as if the
>> > percent parameter isn't recognized and ignored. It always ends up in
>> > "cannot allocate memory". Any hints on this? Do both 'lfs/cdrom' AND
>> > 'lfs/Config' need the '--memory'-parameter?

This was the next problem: 'percent'-parameter does not work as expected.

>> Yes, but it would be good to have one place where the parameters are
>> being generated and then we just use them from a variable.

Probably beyond my capabilities for the moment. Any thoughts?

>> > > > ...
>> > > > We will at least need about half a GB which should be a sensible
>> > > > requirement
>> > > > for a build system any ways.

I'm afraid '500 MiB' are not enough...

>> > Agreed. Because of this I'm testing with '500Mib'.
>> > 
>> > > > Will you work on this bringing it into the build system?!
>> > 
>> > "I'll do my very best!" :-))
>> 
>> Very well Miss Sophie...
>> ...

Best™,
Matthias

  reply	other threads:[~2017-11-21 17:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-06 18:32 Michael Tremer
2017-11-06 21:06 ` Matthias Fischer
2017-11-07 10:44   ` Michael Tremer
2017-11-17 12:59     ` Matthias Fischer
2017-11-17 19:37       ` Matthias Fischer
2017-11-17 21:25         ` Michael Tremer
2017-11-17 23:15           ` Matthias Fischer
2017-11-18  7:44         ` Marcel Lorenz
2017-11-06 21:09 ` Matthias Fischer
2017-11-07 10:46   ` Michael Tremer
2017-11-07 15:05     ` Michael Tremer
2017-11-07 18:41       ` Matthias Fischer
2017-11-07 22:47         ` Michael Tremer
2017-11-21 14:42           ` Michael Tremer
2017-11-21 17:35             ` Matthias Fischer [this message]
2017-11-22 16:37               ` Michael Tremer
2018-01-29 13:23                 ` Compress images with XZ (was: Planning out Core Update 117) Michael Tremer
2018-01-30 16:47                   ` Compress images with XZ Matthias Fischer
2018-01-30 20:03                     ` Michael Tremer
2018-02-03 19:44                       ` Matthias Fischer
2018-02-03 21:09                         ` Matthias Fischer
2018-02-06  1:05                           ` Michael Tremer
2018-02-11 15:35                             ` Matthias Fischer
2018-02-11 19:57                               ` Michael Tremer
2018-05-11 20:27                                 ` Michael Tremer
2018-05-12  0:35                                   ` Tom Rymes
2018-05-12  8:48                                     ` Michael Tremer
2018-05-12 14:14                                   ` Matthias Fischer
2018-05-12 19:40                                     ` Michael Tremer
2017-11-10 11:01 ` Planning out Core Update 117 ummeegge
2017-11-10 12:18   ` Michael Tremer
2017-11-10 13:35     ` ummeegge
     [not found] <7EA8C1E7-14CC-4906-9688-504DA016795D@gmx.com>
2017-11-10 15:36 ` ummeegge
2017-11-18 20:53   ` Horace Michael
2017-11-21 10:25     ` ummeegge
2017-11-21 11:49       ` Michael Tremer
2017-11-21 12:30         ` Horace Michael
2017-11-22 10:30 ummeegge

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=f83a7e53-c735-6ef7-42ac-b9f43e77ffb5@ipfire.org \
    --to=matthias.fischer@ipfire.org \
    --cc=development@lists.ipfire.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