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 > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 03-16-2010, 02:08 PM
Andy Whitcroft
 
Default Built-in modules review

During the karmic cycle we built-in a number of modules. Some as part
of the removal of udev random module loading, and some as a part of
trying to speed up the boot. At that time modprobe was significantly
slower than it is now and it is appropriate to review that decision.

We have also had a number of problems reported wherein people can no
longer parameterise their modules as they wish and/or replace them
easily to test updated features. In one specific case the wrong PATA
driver is binding to the device and as it is built-in there is no longer
a remedy.

I have prepared a summary of the sub-systems and drivers as built-in
currently and added them to the blueprint kernel-lucid-config-review's
spec, at the URL below:

http://tinyurl.com/ygvwbks

Filesystems: we currently have all of the ext2,3,4 filesystems builtin,
plus all of the diagnostics filesystems (procfs et al), and also fuse.
Other than FUSE these are all boot essential. I believe FUSE is
required for automounting which needs confirmation. No changes
required.

Subsystems: of those listed the only one which appears to be a
candidate for modularising is netfilter, I cannot recall this being
required builtin.

Network Protocols: again these seem reasonable, the only candidates for
review being DCB and XFRM, if anyone can confirm that we need those.

ATA Drivers: we have the majority of the PATA and SATA drivers built in.
We already have reported issues with the PATA drivers where blacklisting
could be used as a work around if they were not built in. We are also
exposing users to some level of risk including all these drivers which
are not used. In testing on the reference platform I did see a minor
but measurable performance hit to modularising the SATA driver there.
As we are moving to SATA over time I would propose we pull out all of
the PATA drivers and build in only the 2 or 3 most common SATA drivers.

Input drivers: here most things are modules already. TOUCHSCREEN and
TABLET are possible candidates for modularising.

HID drivers: we already took action to move HID to modules and most of
the actual drivers already appear to be modules. No changes required.

If people are in agreement I will put together a patch set to make these
changes.

Comments?

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-16-2010, 02:51 PM
Chase Douglas
 
Default Built-in modules review

On Tue, Mar 16, 2010 at 11:08 AM, Andy Whitcroft <apw@canonical.com> wrote:
> ATA Drivers: we have the majority of the PATA and SATA drivers built in.
> We already have reported issues with the PATA drivers where blacklisting
> could be used as a work around if they were not built in. *We are also
> exposing users to some level of risk including all these drivers which
> are not used. *In testing on the reference platform I did see a minor
> but measurable performance hit to modularising the SATA driver there.
> As we are moving to SATA over time I would propose we pull out all of
> the PATA drivers and build in only the 2 or 3 most common SATA drivers.

I'm not sure I understand the reasoning for including some, but not
all, of the SATA drivers. If the drivers are mature, and we don't have
or foresee any issues with particular drivers, then why modularize
them? The main reason I see for modularization is if there's active
and useful development versions that people need to fix individual
issues and/or add features. I can see that being the case for
something like HID drivers, but most, if not all, SATA drivers should
be mature in both stability and features at this point, right?

-- Chase

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-16-2010, 03:04 PM
Andy Whitcroft
 
Default Built-in modules review

On Tue, Mar 16, 2010 at 11:51:58AM -0400, Chase Douglas wrote:
> On Tue, Mar 16, 2010 at 11:08 AM, Andy Whitcroft <apw@canonical.com> wrote:
> > ATA Drivers: we have the majority of the PATA and SATA drivers built in.
> > We already have reported issues with the PATA drivers where blacklisting
> > could be used as a work around if they were not built in. *We are also
> > exposing users to some level of risk including all these drivers which
> > are not used. *In testing on the reference platform I did see a minor
> > but measurable performance hit to modularising the SATA driver there.
> > As we are moving to SATA over time I would propose we pull out all of
> > the PATA drivers and build in only the 2 or 3 most common SATA drivers.
>
> I'm not sure I understand the reasoning for including some, but not
> all, of the SATA drivers. If the drivers are mature, and we don't have
> or foresee any issues with particular drivers, then why modularize
> them? The main reason I see for modularization is if there's active
> and useful development versions that people need to fix individual
> issues and/or add features. I can see that being the case for
> something like HID drivers, but most, if not all, SATA drivers should
> be mature in both stability and features at this point, right?

I think that the logical extension to that position is that we should
build in everything which is old and stable? All the drivers which are
built-in get at least initialised which may not be beneficial. Also they
increase the size of the kernel itself. There is a trade off to be had
between those we use often and therefore can benefit from being built-in
against those which would only load on one machine in 1000. IMO.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-16-2010, 03:20 PM
Tim Gardner
 
Default Built-in modules review

On 03/16/2010 09:08 AM, Andy Whitcroft wrote:
> During the karmic cycle we built-in a number of modules. Some as part
> of the removal of udev random module loading, and some as a part of
> trying to speed up the boot. At that time modprobe was significantly
> slower than it is now and it is appropriate to review that decision.
>
> We have also had a number of problems reported wherein people can no
> longer parameterise their modules as they wish and/or replace them
> easily to test updated features. In one specific case the wrong PATA
> driver is binding to the device and as it is built-in there is no longer
> a remedy.
>
> I have prepared a summary of the sub-systems and drivers as built-in
> currently and added them to the blueprint kernel-lucid-config-review's
> spec, at the URL below:
>
> http://tinyurl.com/ygvwbks
>
> Filesystems: we currently have all of the ext2,3,4 filesystems builtin,
> plus all of the diagnostics filesystems (procfs et al), and also fuse.
> Other than FUSE these are all boot essential. I believe FUSE is
> required for automounting which needs confirmation. No changes
> required.
>
> Subsystems: of those listed the only one which appears to be a
> candidate for modularising is netfilter, I cannot recall this being
> required builtin.
>

While not required, its unlikely to have an impact either way. The
netfilter core has no module parameters. All of the filter extensions
are already build as modules.

> Network Protocols: again these seem reasonable, the only candidates for
> review being DCB and XFRM, if anyone can confirm that we need those.
>

Wasn't 'boot essential' one of the requirements for being built-in? I've
never encountered these protocols in real life.


> ATA Drivers: we have the majority of the PATA and SATA drivers built in.
> We already have reported issues with the PATA drivers where blacklisting
> could be used as a work around if they were not built in. We are also
> exposing users to some level of risk including all these drivers which
> are not used. In testing on the reference platform I did see a minor
> but measurable performance hit to modularising the SATA driver there.
> As we are moving to SATA over time I would propose we pull out all of
> the PATA drivers and build in only the 2 or 3 most common SATA drivers.
>

Agreed.

> Input drivers: here most things are modules already. TOUCHSCREEN and
> TABLET are possible candidates for modularising.
>
> HID drivers: we already took action to move HID to modules and most of
> the actual drivers already appear to be modules. No changes required.
>
> If people are in agreement I will put together a patch set to make these
> changes.
>
> Comments?
>
> -apw
>


--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-16-2010, 04:01 PM
Chase Douglas
 
Default Built-in modules review

On Tue, Mar 16, 2010 at 12:04 PM, Andy Whitcroft <apw@canonical.com> wrote:
> On Tue, Mar 16, 2010 at 11:51:58AM -0400, Chase Douglas wrote:
>> On Tue, Mar 16, 2010 at 11:08 AM, Andy Whitcroft <apw@canonical.com> wrote:
>> > ATA Drivers: we have the majority of the PATA and SATA drivers built in.
>> > We already have reported issues with the PATA drivers where blacklisting
>> > could be used as a work around if they were not built in. *We are also
>> > exposing users to some level of risk including all these drivers which
>> > are not used. *In testing on the reference platform I did see a minor
>> > but measurable performance hit to modularising the SATA driver there.
>> > As we are moving to SATA over time I would propose we pull out all of
>> > the PATA drivers and build in only the 2 or 3 most common SATA drivers.
>>
>> I'm not sure I understand the reasoning for including some, but not
>> all, of the SATA drivers. If the drivers are mature, and we don't have
>> or foresee any issues with particular drivers, then why modularize
>> them? The main reason I see for modularization is if there's active
>> and useful development versions that people need to fix individual
>> issues and/or add features. I can see that being the case for
>> something like HID drivers, but most, if not all, SATA drivers should
>> be mature in both stability and features at this point, right?
>
> I think that the logical extension to that position is that we should
> build in everything which is old and stable? *All the drivers which are
> built-in get at least initialised which may not be beneficial. *Also they
> increase the size of the kernel itself. *There is a trade off to be had
> between those we use often and therefore can benefit from being built-in
> against those which would only load on one machine in 1000. *IMO.

I'm trying to figure out the rationale for the decision to include
only some of the SATA modules. If it's really size in the kernel, then
it can make sense to only statically include those modules that are
used often. But there's a tradeoff in speed I assume, so we're sort of
telling one group of people that they have popular hardware so we are
giving them the benefit of speed, but we tell the other group that
they don't have popular hardware, so we aren't giving them the benefit
of speed.

This type of decision sort of gets us down a path of decisions that
are not easily distinguishable. People will start to wonder why some
vendor drivers are included and others are not. If there's a steep
drop off where 99% of users use 3 drivers, and 1% use the other 10
drivers (or however many there are), then this approach can be
articulated easily. But if the gap is more like 33% use the top 3
drivers and 66% use the other 10 drivers, then our stance will be less
clear.

It can also make maintenance harder. If all the modules are static or
dynamic, then we will see the same issues across them. But if we move
the lesser used modules to the initramfs to be loaded dynamically then
we may not have thorough testing on them and we might not find
regressions due to the loading process itself.

What do we really lose by statically building all the SATA modules in?
Is there a known value here, or are we just assuming that there's some
large cost?

-- Chase

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 05:20 AM.

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