Hi,
On Friday 21 May 2010 13:19:44 Daniel Baumann wrote:
> since this is quite a big change for those that do hackish stuff (for
> those, that are using config/* properly, there will nothing change,
> since the binaries are put in the same place as before)..
I just tried it with tmpfs, it's reall
Hi,
Brendan Sleight wrote (23 May 2010 13:17:11 GMT) :
> Benchmarks would be really handy to aid the discussion.
> Even guesses might be useful.
Ok. So I tried building the squeeze branch of T(A)ILS [1].
Here is what "time lh build" reports:
- in tmpfs :
real9m31.897s
user9m27.891s
sys
On 24 May 2010 15:44, Tzafrir Cohen wrote:
>
> Given that it should include roughtly 5 times the size the the binary
> image (or even more), 16MB surely isn't enough. I can't think of a way
> to get a reasonable estimate of it in advance. Note, however, that you
> can specify say, 'size=20%', whi
On Mon, May 24, 2010 at 08:46:41AM +0200, intrigeri wrote:
> Hi,
>
> Tzafrir Cohen wrote (23 May 2010 17:44:54 GMT) :
> > If there's not even swap, I figure that the OOM killer will spring
> > into action. Not sure how it acts with tmpfs, though.
>
> I doubt it. The OOM killer's job is to kill us
Hi,
Tzafrir Cohen wrote (23 May 2010 17:44:54 GMT) :
> If there's not even swap, I figure that the OOM killer will spring
> into action. Not sure how it acts with tmpfs, though.
I doubt it. The OOM killer's job is to kill userspace processes when
the system happens to lack memory.
In a situation
On Sun, May 23, 2010 at 06:51:01PM +0200, intrigeri wrote:
> Hi,
>
> Brendan Sleight wrote (23 May 2010 13:28:02 GMT) :
> > On 21 May 2010 12:19, Daniel Baumann wrote:
> >> can think of: moving everything except the config into build/, and
> >> having build/ on a tmpfs.
> > Maybe a silly question.
Hi,
Brendan Sleight wrote (23 May 2010 13:28:02 GMT) :
> On 21 May 2010 12:19, Daniel Baumann wrote:
>> can think of: moving everything except the config into build/, and
>> having build/ on a tmpfs.
> Maybe a silly question. But what happens if the tmpfs is too small,
> either limitation in hardw
On 21 May 2010 12:19, Daniel Baumann wrote:
> can think of: moving everything except the config into build/, and
> having build/ on a tmpfs.
Maybe a silly question. But what happens if the tmpfs is too small,
either limitation in hardware/swap or set too small by lh ?
Regards,
Brendan
--
To UNS
On 21 May 2010 16:09, intrigeri wrote:
> On a build box with 8GB RAM, building an ISO using tmpfs is *really*
> faster: the IO subsystem stops being the bottleneck, which now is the
> single CPU core speed (apart of mksquashfs, most of the build runs on
> a single CPU)... and the build time decrea
On Fri, May 21, 2010 at 01:19:44PM +0200, Daniel Baumann wrote:
> Hi,
>
> using tmpfs as easy as possible within live-helper would be nice
> (optional, of course, since we can't know the amount of ram and the
> image size to build) in order to speed up the build process a bit, but
> to do that mos
On 05/21/2010 04:49 PM, Daniel Baumann wrote:
> besides.. for those that know what they are doing (e.g. they are sure
> that their host dist is the same as the target distribution), they can
> disable chrooted build. this is present since about two eterneties.
jftr:
live-helper (1.0~a19-1) unstab
Hi,
Jiří Paleček wrote (21 May 2010 14:25:06 GMT) :
> I agree that the build in live-helper could be a lot faster; yet I'm
> not conviced using tmpfs is the right way to go
On a build box with 8GB RAM, building an ISO using tmpfs is *really*
faster: the IO subsystem stops being the bottleneck, wh
On 05/21/2010 04:25 PM, Jiří Paleček wrote:
> there are various other
> opportunities for speed up - for one thing, the chroot/chroot device
> does not help, etc.
chroot/chroot is required in order to ensure to not taint the target
system with the host systems tools (especially when building a dif
Hi,
Daniel Baumann wrote (21 May 2010 11:19:44 GMT) :
> since we can't know the current directy before building, and to avoid
> moving things arround in a hackish way, there's only one solution that i
> can think of: moving everything except the config into build/, and
> having build/ on a tmpfs.
On Fri, 21 May 2010 13:19:44 +0200, Daniel Baumann
wrote:
Hi,
Hello,
using tmpfs as easy as possible within live-helper would be nice
(optional, of course, since we can't know the amount of ram and the
image size to build) in order to speed up the build process a bit, but
to do that most ef
Greetings,
On Fri, May 21, 2010 at 8:03 AM, Marco Amadori wrote:
> In data venerdì 21 maggio 2010 13:19:44, Daniel Baumann ha scritto:
>
>> since we can't know the current directy before building, and to avoid
>> moving things arround in a hackish way, there's only one solution that i
>> can thin
In data venerdì 21 maggio 2010 14:05:28, surreal ha scritto:
> a classic rule of unix - 'if it aint broken, dont fix it'
This is just a bad habit to avoid constant refactoring in bad IT departments.
There is no such a thing like a "unix rule" other than "KISS" [0] and "The art
of Unix programmi
In data venerdì 21 maggio 2010 13:19:44, Daniel Baumann ha scritto:
> since we can't know the current directy before building, and to avoid
> moving things arround in a hackish way, there's only one solution that i
> can think of: moving everything except the config into build/, and
> having build
On 05/21/2010 02:05 PM, surreal wrote:
> a classic rule of unix - 'if it aint broken, dont fix it'
not helpful, it's a non-argument. if there would be anything true about
it, we would be in the stone age still.
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:
a classic rule of unix - 'if it aint broken, dont fix it'
regards.
2010/5/21 Daniel Baumann
> Hi,
>
> using tmpfs as easy as possible within live-helper would be nice
> (optional, of course, since we can't know the amount of ram and the
> image size to build) in order to speed up the build proc
20 matches
Mail list logo
