Re: Dar architecture questions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 16/10/2012 22:09, Kevin Wormington a =E9crit :
> On 10/16/2012 02:42 PM, Denis Corbin wrote:
> On 16/10/2012 17:07, Kevin Wormington wrote:
>>>>> Le 16/10/2012 00:30, Kevin Wormington a =E9crit :
>>>>>> I strace'd the small backup (14k files) both with and without
>>>>>> --disable-special-alloc and it appears the difference is in the huge
>>>>>> number of rt_sigprocmask calls made by special-alloc.
>>>>>
>>>>> interesting... I have tests currently running on my side...
> =

> The so far ran tests also reported huge number of rt_sigprocmask calls
> but they did not have a big impact (see below). I do not know yet
> whether this is caused by the --empty argument or by the 64 bits flavor
> of dar used here. I will do additional tests on Saturday. The used
> system is a Debian stable one with a slightly tuned kernel (kernel with
> less modules and many unused features disabled, but I do not see how
> this may have any concern here).
> =

>> My systems are stock ubuntu server 10.04 LTS and debian 6 all on 64bit =

>> versions of the OS.

Are they multi-core or multiprocessors host? Mine in an not very recent
64bits mono processor host. Linux kernel used had SMP disabled at
compilation time. This might have an impact.

>>>  My configure arguments are the same as yours.  I =

>> did a "make install" between rounds of testing vs running it from the =

>> source directory.  This is probably a dumb question -- but I don't know =

>> your dev environment -- are you doing something to cause the rebuilt =

>> library in the source directory to be used vs the one installed in the =

>> system ld path (assuming there is one)?

doing
	make clean distclean
to clean the tree from object and binary files and then
	./configure [options] && make
rebuilds the libdar library and dar command-line tools from scratch. The
source code relies on libtool, which replaces the src/dar_suite/dar
binary by a script to handle proper linking with the library located in
src/libdar. The real binary can be found in src/dar_suite/.libs but if
you call it directly the dynamic loader of the system will try linking
it with the system's libdar, which is not what you want here.

You can also use --disable-shared with configure, which makes a faster
compilation (as no shared object has to be compiled). In this case no
dynamic link problem occurs (of course :) ), and libtool is not in use
at all so you have the real (statically linked) binary in place. I use
that way of doing for step by step debugging mainly (using the
- --enable-debug option for configure, making it ready for use with gdb).
This let me keep a stable dar binary installed on the system (yes I do
use dar for my own backups!) while I can work and test development
versions of dar/libdar.

So in brief, no need to install the binary to test it.


> =

> =

>> [snip ]
> =


[...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIVAwUBUH3N6ggxsL0D2LGCAQLTvxAAiMg1wY11/ltKxLRLU7Wsonp1N2Vs0DUt
r8XEhvqmauHK4GlMQM42+l8BnvmWOTYfqyr7vCRePlo/nkzLGbGYBuxycpw1FA8U
ywqSzXizZsbsA5tMQkl+cixv1Chz/ZGBgT+II9QS/nQidyA5nPkBKzp0F2vmD+tm
BNwG/XQoclGqnoEyVq8elPpls9LiGFzQ+DbmwNzecusiNiwY68puQoyqfr7o6pLP
S+HVuwkAlAD1o3KdCWmDCt0AvH2El08rSUi31svOEW3T4/BXJeLAisx20A92b81Z
A/Que+43PUaYcinT+WdBj7se9Pb77K5sWGE8v7lGdUNod1eaK3gyXHz2GcWjovr+
fU7T+MGCZP9l43Yy3TZhpQyrOfO8lf7YdWiIepf9yg+YDO2Um/roldXnpZDD3YJ5
CW3wIzWNjAd+vCMt2uU21UtpslHI4jIWu9XElb6iTKgP0qXvwAnLCMx4jL8yUXNx
JL3Zws1R+FMCCzTREHA5CvQwBHpP+aC+86Ds67yG2dHPxFm8z8f87pPNZiasrs9W
Q1qstvkhUYeDOxFsi6uI7moFr0aVttseRD2ZUVI+wbQJTwkVMhA8oRBnAJaUvJFG
EiFpRK2ee/Ufo/ZKW6MSnhASYwBEnwHvSCPmSbvrWyUFtIqp8qBi9vzQvtQYrXxV
PCBLdGxbVuw=3D
=3Du+hz
-----END PGP SIGNATURE-----

---------------------------------------------------------------------------=
---
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct