Re: A really "big" kernel (in a dead weight)
by Kyle McMartin
On Wed, Jan 07, 2009 at 11:20:20PM -0700, Michal Jaegermann wrote:
> I tried to install kernel-2.6.29-0.12.rc0.git7.fc11.x86_64. Its rpm
> package is quite reasonable 24M in size. Only rpm started to complain
> about insufficient space on /. A check with 'rpm -qip ...' revealed
> that the package claims to expand to 1035938542 bytes. Around 1 gig!
>
> Unpacking this in some other place revealed that indeed
> lib/modules/2.6.29-0.12.rc0.git7.fc11.x86_64/ eats 997M of disk.
> Only this is heavily padded with null bytes. With
> 'cp -a --sparse=always ...' aplied to that tree a target drops
> in size to 76M. More than a thirteenfold reduction.
>
> It is true that the same operation performed on
> lib/modules/2.6.29-0.9.rc0.git4.fc11.x86_64 reduces that from 188M
> to 78M, which is still quite a lot, but what 2.6.29-0.12.rc0.git7.fc11
> is doing seems to be somewhat excessive. Is this is a side effect
> of some changes in a build process? Something seems to be a tad
> pushy.
>
> That "module fattening" surely adds a lot of extra time to kernel
> installation scripts but other than that a kernel for which modules
> were made sparse boots as any other one. The latest updates caused
> other serious and so far mysterious breakage, and in particular
> haldaemon does not run for me anymore, but that does look like a
> kernel dependent.
>
Hitting up fedora-kernel-list would be helpful. ;-)
Any idea which revision this was introduced in? If not, I'll start
poking koji.
cheers, Kyle
14 years, 9 months
Re: Enabling drivers in staging tree in rawhide
by Thorsten Leemhuis
CCing fedora-kernel
On 08.01.2009 03:49, Rahul Sundaram wrote:
> Quite a bit of new drivers in
> http://lwn.net/Articles/313730/
Related: I raised the staging problem already in
https://bugzilla.redhat.com/show_bug.cgi?id=477927
as rawhide contained the at76 driver as separate patch
http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patc...
-- but the same driver (with two small changes) also was part of the
upstream kernel since October/2.6.28-rc as one of the staging drivers:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...
(for more details see bug).
That sounds wrong to me, as
- it's duplicated work
- the at76 staging driver from upstream taints the kernel; the driver
from our patch doesn't.
> The ralink wireless drivers for example would hopefully make the newer
> EEE PC model would out of the box. Does it make sense to enable the
> drivers in staging tree by default and bring more exposure to them
> atleast via rawhide if not in general releases?
+1 to the "I think providing hardware support in rawhide and then
removing it before release would be somewhat user-hostile." comment
from mjg59.
IOW: Either enable or disable them. I'm unsure myself what to do but I
tend to say that disabling the whole staging drivers might be the best
for Fedora (Greg calls himself as "maintainer of crap" for a good reason).
@Davej, Cebbert and Kylem: What's your position on this?
If they are disabled completely in Fedora then I'll nevertheless
consider to create a "kmod-staging" package for RPM Fusion.
CU
knurd
14 years, 9 months
/proc/sys/fs/epoll/max_user_instances=128 considered harmful
by Joe Orton
The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by
default. Apache httpd uses one epoll fd ("instance") per child process,
so this sets a hard limit on 128 children (i.e. 100 concurrent clients)
out of the box.
1) shouldn't this be an rlimit so that we can bump it appropriately in
the parent as root?
2) can we get it tweaked in the default sysctl.conf to be something more
sane, e.g. 1024?
Regards, Joe
14 years, 9 months
