[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKHv7pi4YtzdR-8UqGFCk_bgVmgtu=DdFb0-O2cJ6mM0hj9Kjg@mail.gmail.com>
Date: Thu, 3 Oct 2013 10:56:10 +0200
From: Paul Schutte <sjpschutte@...il.com>
To: sabotage@...ts.openwall.com
Subject: Re: Installing everything in opt
Hi,
Sorry for bringing this up again but I am having trouble building it
without symlinks.
I have in the butch_template_configure_cached.txt file:
# note that you could set similar stuff using env variables.
butch_do_config_cache=true
butch_do_cleanup_builddir=true
butch_do_custom_destdir=false
# the options below all require a custom destdir to be set.
butch_do_cleanup_custom_destdir=false
butch_do_relocate=false
butch_do_filelists=true
butch_do_create_tarball=false
'build-stage 0' fails when getting to building musl:
cat /mnt/sbuild/src/logs/build_stage0_musl.log
Wed Oct 2 14:03:13 SAST 2013: start
sourcing user defined optimization config /mnt/sbuild/etc/butch-optflags.sh
Wed Oct 2 14:03:13 SAST 2013: starting to untar
Wed Oct 2 14:03:13 SAST 2013: untar done
Wed Oct 2 14:03:13 SAST 2013: start build
checking for C compiler... /mnt/sbuild/bin/gcc
checking target system type... unknown
./configure: unable to detect target arch; try ./configure --target=...
Any help will be appreciated.
Regards
Paul
On Mon, Sep 23, 2013 at 3:45 PM, John Spencer <maillist-musl@...fooze.de>wrote:
> On 09/23/2013 02:36 PM, Christian Neukirchen wrote:
>
>> Paul Schutte<sjpschutte@...il.com> writes:
>>
>> Hi Guys,
>>>
>>> I apologize in advance if I step on someone toes with this post.
>>>
>>> Performance wise it is very bad to put everything in /opt and using
>>> symlinks.
>>>
>>> lets look at an example of a binary called test1 that uses three dynamic
>>> libraries.
>>>
>>> In a "normal" installation it will go something like this:
>>>
>>> dirlookup(/bin)->inodelookup(/**bin)->dirlookup(test1)->**
>>> inodelookup(test1)->load(**test1)
>>>
>>>
>>> In the "symlink" installation it will go something like this:
>>>
>>> dirlookup(/bin)->inodelookup(/**bin)->dirlookup(test1)->**
>>> inodelookup(test1)->**readsymlink(test1)
>>> ->dirlookup(/opt)->**inodelookup(/opt)->dirlookup(**
>>> test1dir)->inodelookup(**test1dir)
>>> ->dirlookup(/bin)->**inodelookup(/bin)->->**
>>> dirlookup(test1)->inodelookup(**test1)
>>>
>>> 5 operations vs 13 operations.
>>>
>>> If we take into account the 3 libraries we are at 20 ops vs 52.
>>>
>>> If we asume SATA with 8ms average seek, this will be 0.16s vs 0.416s seek
>>> time for the same binary.
>>>
>>> One might argue that the meta data will be cached and therefore the
>>> penalty
>>> is not that bad.
>>>
>>
>> It would be interesting to benchmark the actual performance loss,
>> e.g. of a kernel build with toolchain in /usr vs symlinked.
>>
>>
> yes, seeing some real-world performance numbers would be interesting.
>
> i doubt that it makes a noticable difference, and it's gonna be much
> faster than a glibc based system either way, due to musl's
> syscall-optimized startup code.
>
> btw, sabotage makes it really trivial to change the way packages are
> installed. if you don't want to use the one-package-per-dir strategy, and
> the flexible symlink management (butch unlink, butch relink, etc) you can
> edit KEEP/butch_template... and change the variables
> butch_do_custom_destdir=true
> butch_do_cleanup_custom_**destdir=true
> butch_do_relocate=true
> to false.
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
