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 > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-05-2011, 09:00 AM
Nikos Chantziaras
 
Default Last rites: www-client/chromium-bin

On 03/05/2011 04:41 AM, Rich Freeman wrote:

On Fri, Mar 4, 2011 at 6:46 PM, Alex Alexander<wired@gentoo.org> wrote:

Anyway, compilation on a modern system shouldn't take more than an
hour. ~15-20 minutes on a quad i5.


Clearly your definition of modern doesn't include my server...
Just checked and the last build clocked in at 192 minutes. I need to
make sure I have /var/tmp/portage symlinked back to a non-tmpfs
location whenever I build it or else the system pretty-much dies from
a lack of RAM.


Then I'd say you have your tmpfs mount options configured wrongly :-)
You should specify a maximum amount of RAM it should use. When it fill
up, it then uses swap.
 
Old 03-05-2011, 09:05 AM
Nikos Chantziaras
 
Default Last rites: www-client/chromium-bin

On 03/05/2011 12:00 PM, Nikos Chantziaras wrote:

On 03/05/2011 04:41 AM, Rich Freeman wrote:

On Fri, Mar 4, 2011 at 6:46 PM, Alex Alexander<wired@gentoo.org> wrote:

Anyway, compilation on a modern system shouldn't take more than an
hour. ~15-20 minutes on a quad i5.


Clearly your definition of modern doesn't include my server...
Just checked and the last build clocked in at 192 minutes. I need to
make sure I have /var/tmp/portage symlinked back to a non-tmpfs
location whenever I build it or else the system pretty-much dies from
a lack of RAM.


Then I'd say you have your tmpfs mount options configured wrongly :-)
You should specify a maximum amount of RAM it should use. When it fill
up, it then uses swap.


I take that back. It seems you can't do that with tmpfs :-(
 
Old 03-05-2011, 09:05 AM
Duncan
 
Default Last rites: www-client/chromium-bin

Paweł Hajdan, Jr. posted on Sat, 05 Mar 2011 10:23:34 +0100 as excerpted:

> On 3/5/11 12:58 AM, Alex Alexander wrote:
>> I can also give you a binpkg from one of my chroots :P
>
> It sounds like a possible option. We could then advertise those binpkgs
> on the project page, or make them semi-official. If you or someone else
> is interested in doing that, I second that effort.

What about handling chromium-bin the same way amd64 handles grub-static?
They create a standard binpkg of the normal grub ebuild (using
standardized USE flags, of course), using that as the source tarball for
the grub-static ebuild, which then simply ebuild-scripts the unpack and
install of the binpkg tarball.

In theory, the ebuild could even grab and merge the appropriate binpkg
based on arch, allowing the ebuild to be keyworded for more archs than the
usual binary-only ebuild tends to be, altho I'm not sure that'd work in
practice as I'm unsure of the effects on the metadata cache and whether
that would be allowed or not.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 03-05-2011, 09:21 AM
Dale
 
Default Last rites: www-client/chromium-bin

Nikos Chantziaras wrote:

On 03/05/2011 12:00 PM, Nikos Chantziaras wrote:

On 03/05/2011 04:41 AM, Rich Freeman wrote:

On Fri, Mar 4, 2011 at 6:46 PM, Alex Alexander<wired@gentoo.org> wrote:

Anyway, compilation on a modern system shouldn't take more than an
hour. ~15-20 minutes on a quad i5.


Clearly your definition of modern doesn't include my server...
Just checked and the last build clocked in at 192 minutes. I need to
make sure I have /var/tmp/portage symlinked back to a non-tmpfs
location whenever I build it or else the system pretty-much dies from
a lack of RAM.


Then I'd say you have your tmpfs mount options configured wrongly :-)
You should specify a maximum amount of RAM it should use. When it fill
up, it then uses swap.


I take that back. It seems you can't do that with tmpfs :-(




It seems you correct the first time.

http://en.wikipedia.org/wiki/Tmpfs

I found the same examples in other paces as well. One is in the mount
man page.


Dale

:-) :-)
 
Old 03-05-2011, 09:29 AM
Rich Freeman
 
Default Last rites: www-client/chromium-bin

On Sat, Mar 5, 2011 at 5:00 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 03/05/2011 04:41 AM, Rich Freeman wrote:
>> I need to
>> make sure I have /var/tmp/portage symlinked back to a non-tmpfs
>> location whenever I build it or else the system pretty-much dies from
>> a lack of RAM.
>
> Then I'd say you have your tmpfs mount options configured wrongly :-) You
> should specify a maximum amount of RAM it should use. *When it fill up, it
> then uses swap.
>

So, your later redaction aside, I should say that the kernel devs have
their swap behavior wrong in any case.

Think about it - if you write to a disk-based filesystem every byte
that you write ends up on disk, subject to cache (with little
discretion - all data needs to be written out within 30 seconds or
so).

If you have very little RAM free the tmpfs should really be no worse
since there too every byte that gets written gets swapped to disk.
However, the kernel has complete discretion about when this happens,
whether this happens at all, and it gets to write it in a partition
optimized for this purpose without regard for long-term
preservation/etc. Yet, for whatever reason all this swapping seems
slower.

The likely reason is that the kernel isn't that good at figuring out
what to swap and what not to swap. It might be prioritizing keeping
some object files around in RAM on a tmpfs while trying to swap in/out
some other process that keeps getting woken up or whatever.

Better swap behavior should let the tmpfs perform better than
ext4/etc, since it gives the kernel more discretion about what to
write out and when.
 
Old 03-05-2011, 09:41 AM
Rich Freeman
 
Default Last rites: www-client/chromium-bin

On Sat, Mar 5, 2011 at 5:21 AM, Dale <rdalek1967@gmail.com> wrote:
> It seems you correct the first time.
>
> http://en.wikipedia.org/wiki/Tmpfs
>
> I found the same examples in other paces as well. *One is in the mount man
> page.

While this is drifting off-topic this is not the case. You can limit
the size of a tmpfs, but you can't limit the amount of physical RAM
that it uses (other than its size limit). At least, not using
anything in either of those sources.

When building chromium limiting the tmpfs size isn't a very practical
solution... At least, not until that contrib directory doesn't have
half a gig of stuff already on my system BEFORE I compile it.
 
Old 03-10-2011, 10:12 AM
"Paweł Hajdan, Jr."
 
Default Last rites: www-client/chromium-bin

On 3/5/11 11:05 AM, Duncan wrote:
> What about handling chromium-bin the same way amd64 handles grub-static?
> They create a standard binpkg of the normal grub ebuild (using
> standardized USE flags, of course), using that as the source tarball for
> the grub-static ebuild, which then simply ebuild-scripts the unpack and
> install of the binpkg tarball.

That's the chromium-bin, really. The difference is that chromium has
more deps and takes more time to compile than grub. Also, it has much
more frequent releases, and almost every stable release is a security
update.

> In theory, the ebuild could even grab and merge the appropriate binpkg
> based on arch, allowing the ebuild to be keyworded for more archs than the
> usual binary-only ebuild tends to be, altho I'm not sure that'd work in
> practice as I'm unsure of the effects on the metadata cache and whether
> that would be allowed or not.

Yeah, I can understand how it could work technically. The only issue is
to make the version bump one automated step.

Paweł Hajdan, Jr.
 
Old 03-10-2011, 07:04 PM
James Cloos
 
Default Last rites: www-client/chromium-bin

>>>>> "PH" == Paweł Hajdan, <phajdan.jr@gentoo.org> writes:

PH> That's the chromium-bin, really. The difference is that chromium has
PH> more deps and takes more time to compile than grub. Also, it has much
PH> more frequent releases, and almost every stable release is a security
PH> update.

And every one of those chromium releases is another 200 Meg download.

Or is that yet another?

Still yet another?

-JimC (who still prefers the src)
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
 
Old 03-10-2011, 07:33 PM
Mike Gilbert
 
Default Last rites: www-client/chromium-bin

On Thu, Mar 10, 2011 at 3:04 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "PH" == Paweł Hajdan, <phajdan.jr@gentoo.org> writes:
>
> PH> That's the chromium-bin, really. The difference is that chromium has
> PH> more deps and takes more time to compile than grub. Also, it has much
> PH> more frequent releases, and almost every stable release is a security
> PH> update.
>
> And every one of those chromium releases is another 200 Meg download.
>
> Or is that yet another?
>
> Still yet another?

Chromium tarballs are actually around 140 MB. It would be interesting
to see if we can trim that tarball down.

For comparison, Firefox weighs in at about 50 MB.
 
Old 03-10-2011, 07:42 PM
"Paweł Hajdan, Jr."
 
Default Last rites: www-client/chromium-bin

On 3/10/11 9:33 PM, Mike Gilbert wrote:
> Chromium tarballs are actually around 140 MB. It would be interesting
> to see if we can trim that tarball down.

Oh yes, we can. I guess the biggest problem is testing, but we can
certainly remove more from the tarball.

If anyone's interested, it's src/tools/export_tarball/export_tarball.py
in the Chromium source tree. I can review patches. :-D

Paweł Hajdan, Jr.
 

Thread Tools




All times are GMT. The time now is 10:33 PM.

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