FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-12-2011, 01:12 PM
Jarek Kamiński
 
Default Upcoming FTPMaster meeting

Na grupie linux.debian.devel napisałe(a)ś:
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> type that are going to run stock Debian are chroots on n900, which, with
> 256MB, can handle all the phony stuff together with decompression just fine.
> If you allow for everything but the decompression to be swapped out, even
> 128MB would work reasonably.

No, it's not:
#v+
[jarek@archeress ~]% free -m
total used free shared buffers cached
Mem: 60 58 2 0 10 16
-/+ buffers/cache: 31 29
Swap: 511 55 456
#v-

Lenny with (by memory usage): bind, openssh, snmpd, postfix, cups,
dhcp3, ntpd, upnpd, hostapd, mt-daapd, ... works just fine. I could
reduce the memory requirements even more by throwing away some services
and replacing bind with something lighter, but it wasn't necessary.

--
pozdr(); // Jarek


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110212141232.GA30032@vilo.eu.org">http://lists.debian.org/20110212141232.GA30032@vilo.eu.org
 
Old 02-12-2011, 01:17 PM
Paul Wise
 
Default Upcoming FTPMaster meeting

On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski <kilobyte@angband.pl> wrote:

> On ARM, it's 90MB, I guess MIPS should be similar.
> The man page says 65MB even in -9, but I guess they didn't count in the
> code, libc, buffers and the likes.
>
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> type that are going to run stock Debian are chroots on n900, which, with
> 256MB, can handle all the phony stuff together with decompression just fine.
> If you allow for everything but the decompression to be swapped out, even
> 128MB would work reasonably.
>
> Anything lower and you go into emdebian, which repacks all the packages
> anyway.
>
> Thus, I think there are no problems with enabling XZ on all architectures.

My OpenMoko FreeRunner phone is an ARM device that has 128Mb RAM and
runs pure Debian armel. Only time I need to kill things to during an
upgrade is when I'm upgrading the locales package or lintian, creating
locales files seems to take a lot of memory and the process gets
killed sometimes.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikjo2U4EZ+Yz_NUPEqdU0bRO9i3HioQuUPsjfVH@mail .gmail.com">http://lists.debian.org/AANLkTikjo2U4EZ+Yz_NUPEqdU0bRO9i3HioQuUPsjfVH@mail .gmail.com
 
Old 02-12-2011, 01:21 PM
Olaf van der Spek
 
Default Upcoming FTPMaster meeting

On Sat, Feb 12, 2011 at 3:06 PM, Andrey Rahmatullin <wrar@wrar.name> wrote:
>> 128MB would work reasonably.
> I think that VPS'es with 128Mb RAM are still sold, not to mention existing
> installations.

May enable it on x64 first (those 128 mb VPSs are unlikely to run x64)
and then see about other archs later.

--
Olaf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTi=Gpi+w_VfAEvp1wPS3=5VZz5QPSTAZDRv6pgFK@mail .gmail.com">http://lists.debian.org/AANLkTi=Gpi+w_VfAEvp1wPS3=5VZz5QPSTAZDRv6pgFK@mail .gmail.com
 
Old 02-12-2011, 03:02 PM
Raphael Hertzog
 
Default Upcoming FTPMaster meeting

On Sat, 12 Feb 2011, Philipp Kern wrote:
> Do we have an idea how much more memory xz needs for decompression? I guess
> it wouldn't be feasible to switch dpkg's default on package builds on those
> architectures where we assume some more beefyness?

It depends on what compression level we use, this is in the manpage:

The following table summarises the features of the presets:
Preset DictSize CompCPU CompMem DecMem
-0 256 KiB 0 3 MiB 1 MiB
-1 1 MiB 1 9 MiB 2 MiB
-2 2 MiB 2 17 MiB 3 MiB
-3 4 MiB 3 32 MiB 5 MiB
-4 4 MiB 4 48 MiB 5 MiB
-5 8 MiB 5 94 MiB 9 MiB
-6 8 MiB 6 94 MiB 9 MiB
-7 16 MiB 6 186 MiB 17 MiB
-8 32 MiB 6 370 MiB 33 MiB
-9 64 MiB 6 674 MiB 65 MiB

"DecMem" is the memory needed to decompress (i.e. install the package),
"CompMem" is the memory needed to compress (i.e. create the package).

I think we could use -6 on all architectures without much problem. It's also
the default setting used by xz if you don't specify anything.

> I'd imagine that our CD1s would also get more useful if we'd compress those
> in any case.

Yeah, it's those discussions about our CD1 that led me to push this forward again.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110212160218.GE23482@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110212160218.GE23482@rivendell.home.ouaza.com
 
Old 02-12-2011, 03:02 PM
Raphael Hertzog
 
Default Upcoming FTPMaster meeting

On Sat, 12 Feb 2011, Philipp Kern wrote:
> Do we have an idea how much more memory xz needs for decompression? I guess
> it wouldn't be feasible to switch dpkg's default on package builds on those
> architectures where we assume some more beefyness?

It depends on what compression level we use, this is in the manpage:

The following table summarises the features of the presets:
Preset DictSize CompCPU CompMem DecMem
-0 256 KiB 0 3 MiB 1 MiB
-1 1 MiB 1 9 MiB 2 MiB
-2 2 MiB 2 17 MiB 3 MiB
-3 4 MiB 3 32 MiB 5 MiB
-4 4 MiB 4 48 MiB 5 MiB
-5 8 MiB 5 94 MiB 9 MiB
-6 8 MiB 6 94 MiB 9 MiB
-7 16 MiB 6 186 MiB 17 MiB
-8 32 MiB 6 370 MiB 33 MiB
-9 64 MiB 6 674 MiB 65 MiB

"DecMem" is the memory needed to decompress (i.e. install the package),
"CompMem" is the memory needed to compress (i.e. create the package).

I think we could use -6 on all architectures without much problem. It's also
the default setting used by xz if you don't specify anything.

> I'd imagine that our CD1s would also get more useful if we'd compress those
> in any case.

Yeah, it's those discussions about our CD1 that led me to push this forward again.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110212160218.GE23482@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110212160218.GE23482@rivendell.home.ouaza.com
 
Old 02-12-2011, 03:19 PM
Guillem Jover
 
Default Upcoming FTPMaster meeting

Hi!

On Sat, 2011-02-12 at 13:15:47 +0000, Philipp Kern wrote:
> On 2011-02-11, Hideki Yamane <henrich@debian.or.jp> wrote:
> > On Fri, 4 Feb 2011 08:20:02 +0100
> > Raphael Hertzog <hertzog@debian.org> wrote:
> >> I have not seen any word about XZ support.
> >> When you deployed support for new source package formats, you forbid
> >> lzma because xz was coming along and you mentioned that wheezy could have
> >> xz enabled.
> >> I would like to see xz allowed both for source package and for binary
> >> packages.
> > I want XZ support too, at least it reduce size for some font packages.
> > e.g.

> Do we have an idea how much more memory xz needs for decompression?

We changed the default compression level for lzma to -6, and set it as
the default for xz on the initial addition to dpkg-deb in 1.15.6,
exactly for the memory reasons, taking into account small systems and
to open the possibility of a possible future default switch. I think
xz and lzma memory usage might vary slightly but for xz -6 the man
page says 9 MiB on decompression, which should be fine everywhere.

> I guess it wouldn't be feasible to switch dpkg's default on package builds
> on those architectures where we assume some more beefyness?

It would be possible, but I'd rather not do that, as even if some
architectures are prone to have more memory generally, that's an
exclusive charecteristic of the system, and the decisions to exclude
specific architectures would seem somehow arbitrary (I'm sure there's
still people using Debian on i486), and Debian specific. When changing
the dafault for dpkg-deb, it should be changed for everything.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110212161904.GA27660@gaara.hadrons.org">http://lists.debian.org/20110212161904.GA27660@gaara.hadrons.org
 
Old 02-12-2011, 03:19 PM
Guillem Jover
 
Default Upcoming FTPMaster meeting

Hi!

On Sat, 2011-02-12 at 13:15:47 +0000, Philipp Kern wrote:
> On 2011-02-11, Hideki Yamane <henrich@debian.or.jp> wrote:
> > On Fri, 4 Feb 2011 08:20:02 +0100
> > Raphael Hertzog <hertzog@debian.org> wrote:
> >> I have not seen any word about XZ support.
> >> When you deployed support for new source package formats, you forbid
> >> lzma because xz was coming along and you mentioned that wheezy could have
> >> xz enabled.
> >> I would like to see xz allowed both for source package and for binary
> >> packages.
> > I want XZ support too, at least it reduce size for some font packages.
> > e.g.

> Do we have an idea how much more memory xz needs for decompression?

We changed the default compression level for lzma to -6, and set it as
the default for xz on the initial addition to dpkg-deb in 1.15.6,
exactly for the memory reasons, taking into account small systems and
to open the possibility of a possible future default switch. I think
xz and lzma memory usage might vary slightly but for xz -6 the man
page says 9 MiB on decompression, which should be fine everywhere.

> I guess it wouldn't be feasible to switch dpkg's default on package builds
> on those architectures where we assume some more beefyness?

It would be possible, but I'd rather not do that, as even if some
architectures are prone to have more memory generally, that's an
exclusive charecteristic of the system, and the decisions to exclude
specific architectures would seem somehow arbitrary (I'm sure there's
still people using Debian on i486), and Debian specific. When changing
the dafault for dpkg-deb, it should be changed for everything.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110212161904.GA27660@gaara.hadrons.org">http://lists.debian.org/20110212161904.GA27660@gaara.hadrons.org
 
Old 02-12-2011, 03:22 PM
Guillem Jover
 
Default Upcoming FTPMaster meeting

Hi!

On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
> On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > Since there is no support for auto-building arch-independent binaries
>
> I would hope that throwing away developer built debs would also apply
> to arch-independent packages, IIRC that was part of the proposal.
> There was talk of a Build-Architecture field for Architecture: all
> stuff that can only be built on certain architectures (firmware,
> bootloaders etc where there is no cross-compiler available).

Using Build-Architecture would be a workaround, it should not be
needed once multiarch is in place and those packages are built for
their respective architectures.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110212162230.GB27660@gaara.hadrons.org">http://lists.debian.org/20110212162230.GB27660@gaara.hadrons.org
 
Old 02-12-2011, 04:04 PM
Adam Borowski
 
Default Upcoming FTPMaster meeting

On Sat, Feb 12, 2011 at 10:17:59PM +0800, Paul Wise wrote:
> On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski <kilobyte@angband.pl> wrote:
>
> > On ARM, it's 90MB, I guess MIPS should be similar.
> > The man page says 65MB even in -9, but I guess they didn't count in the
> > code, libc, buffers and the likes.
> >
> My OpenMoko FreeRunner phone is an ARM device that has 128Mb RAM and
> runs pure Debian armel. Only time I need to kill things to during an
> upgrade is when I'm upgrading the locales package or lintian, creating
> locales files seems to take a lot of memory and the process gets
> killed sometimes.

Decompression and generation of locale files never go together, so this
shouldn't be a problem.

As others have noticed, reducing the compression level can reduce memory
requirement to a single digit, and that dpkg-dev already uses -6 rather than
-9 by default. I believe it might be a good idea to go back to -9 on big
architectures, but this is a detail that can be changed later. For now,
it's important to know if it's save to enable xz everywhere, and it appears
it is. If indeed xz -6 takes only 9MB to decompress, even Jarek's machine
with 64MB should handle it without a swappeathon.

I didn't check this myself, but I'm told that when xz has to swap (and not
merely evict other processes away), its memory usage pattern is so bad that
a file normally processed in ten seconds can take an hour. Thus, using 9MB
vs 90 makes quite a difference.

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110212170423.GA9739@angband.pl">http://lists.debian.org/20110212170423.GA9739@angband.pl
 
Old 02-12-2011, 05:54 PM
Joey Hess
 
Default Upcoming FTPMaster meeting

Adam Borowski wrote:
> Trying to run unmodified Debian on 64MB is a suicide

The NSLU2 is still a supported platform, it runs in 32 mb. More or less
happily IME.

> Thus, I think there are no problems with enabling XZ on all architectures.

I see little benefit to enabling it on arm. Size of arm CDs is rarely a
concern, since basically nobody ever uses those CDs.

--
see shy jo
 

Thread Tools




All times are GMT. The time now is 03:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org