Re: [PATCH 2/2] hotplug resource limitation

[Hannes Reinecke]

Greg KH wrote:
> On Tue, Aug 10, 2004 at 10:10:02AM +0200, Hannes Reinecke wrote:
>
> > Greg KH wrote:
> >
> > > On Mon, Aug 09, 2004 at 03:07:15PM +0200, Hannes Reinecke wrote:
> > >
> > >
> > > > Hi all,
> > > > this is the second patch to implement hotplug resource limitation 
> > > > (relative to 2.6.7-rc2-mm2).
> > > >
> > > > In some cases it is preferrable to adapt the number of concurrent 
> > > > hotplug processes on the fly in addition to set the number statically 
> > > > during boot.
> > >
> > >
> > > Why?  This should be "auto-tuning".  We don't want to provide
> > > yet-another-knob-for-people-to-tweak-from-userspace, right?
> >
> > In principle you're right. But as we don't really now how much resources 
> > the installed hotplug program will require I don't really see another way.
>
>
> But who is going to know how to tweak such a knob?  How will an admin
> know they should reduce the number of outstanding processes?
Documentation?

> > > > Additionally, it might be required to disable hotplug / 
> > > > kmod event delivery altogether for debugging purposes (e.g. if a module 
> > > > loaded automatically is crashing the machine).
> > >
> > >
> > > Ugh, that's just not a good thing at all.  You can do that by running:
> > > 	echo /bin/true > /proc/sys/kernel/hotplug
> > > today if you have to.  I don't like the ability to stop the kernel from
> > > running properly, like this patch allows you to.
> >
> > But then you'll lose all events which happen in the meantime.
>
>
> Yup.
>
>
> > The dynamic setting is mainly intended for two scenarios:
> > - Booting. You can disable all events on boot with the kernel 
> > commandline and re-enable them once your hotplug subsystem is up and 
> > running. This way you can handle all (ok, all devices appearing in 
> > sysfs) device with hotplug events; there is no need to regenerate / fake 
> > all events which might have been missed. Currently you need two sets of 
> > scripts, one for configuring all devices until hotplug is running and 
> > another one used by hotplug.
>
>
> Or just put hotplug into your initramfs to catch all of the events from
> the beginning of kernel time.
Unfortunately this does not quite work as of today.
Open issues:
- udp sockets are not available during early stages, making it 
impossible to use udevsend/udevd
- No initial hook is given, which would allow for a setup of the 
initramfs (e.g. mounting of /dev on ramfs). Relying to catch event with 
SEQNUM 0 is dodgy (as it might well be that we never get this one); 
checking on every event ditto (as one might want to use 'udev' as 
hotplug program).
- Synchronisation of configuration files is hard to solve; either you 
have to update the initramfs every time after a device has been 
reconfigured or you do some sort of auto-detection, in which case you 
have to pack in every module etc. into the initramfs.

> Actually, we currently only have 1 set of scripts that do the hotplug
> work.  We have an additional one that makes some "fake" hotplug events
> at init time to catch the events that we were not able to catch.  So we
> still only have 1 main code path.
But IMHO the main advantage of having initramfs is that we can get rid 
of this 'coldplug' / fake hotplug event stuff as we're able to catch all 
events. Otherwise I don't really see the point in initramfs.

> > - Debugging. Especially laptops or legacy free machines do have the 
> > problem that hotplug scripts might misconfigure the machine, e.g. by 
> > loading the wrong module. Of course it's possible to keep this 'disable 
> > hotplug events on request' (which should event available during boot) 
> > entirely in userspace. But it would increase the size of /sbin/hotplug 
> > (and hence the running time) by quite a bit; and this would bite us on 
> > every hotplug event generated resulting in a general slowdown of the 
> > hotplug subsystem.
>
>
> I'd be very supprised if you could actually measure the hit of adding 2
> more lines of bash to those hotplug scripts.  They aren't exactly the
> fastest thing in the world in the first place, nor do they need to be.
But we want to keep the initial 'hotplug' script as small/fast as 
possible, as this script is called by _every_ event.
Any subsequent script (e.g. agents) do not really matter, as they are 
called much more infrequently (here on my local desktop machine I have a 
ration of 10:1).

> > If we can stop the hotplug event delivery from within the kernel, we
> > can keep the main hotplug script as small as possible while retaining
> > the functionality of temporarily disabling all hotplug events.
>
>
> So, add kernel complexity in order to reduce userspace complexity?  I
> don't think that argument is going to win here :)
Unfair argument :-).

Cheers,

Hannes
--
Dr. Hannes Reinecke			hare@xxxxxxx
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/