From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Date: Tue, 27 Jul 2004 07:04:08 +0000 Subject: Re: [PATCH] Limit number of concurrent hotplug processes Message-Id: <4105FE68.7040506@suse.de> List-Id: References: <40FD23A8.6090409@suse.de> <20040725182006.6c6a36df.akpm@osdl.org> <4104E421.8080700@suse.de> <20040726131807.47816576.akpm@osdl.org> In-Reply-To: <20040726131807.47816576.akpm@osdl.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Andrew Morton Cc: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Andrew Morton wrote: > Hannes Reinecke wrote: >=20 >> >> Any comments/suggestions welcome; otherwise please apply. >> >=20 >> >=20 >> > I suggest you just use a semaphore, initialised to a suitable value: >> >=20 >> >=20 >> > static struct semaphore foo =3D __SEMAPHORE_INITIALIZER(foo, 50); >> >=20 >> >=20 >> > { >> > ... >> > down(&foo); >> > ... >> > up(&foo); >> > ... >> > } >> >=20 >> Hmm; looks good, but: It's not possible to reliably change the maximum=20 >> number of processes on the fly. >> >> The trivial way of course it when the waitqueue is empty and no=20 >> processes are holding the semaphore. But it's quite non-obvious how this= =20 >> should work if processes are already holding the semaphore. >> We would need to wait for those processes to finish, setting the length = >> of the queue to 0 (to disallow any other process from grabbing the=20 >> semaphore), and atomically set the queue length to the new value. >> Apart from the fact that we would need a worker thread for that=20 >> (otherwise the calling process might block indefinitely), there is no=20 >> guarantee that the queue ever will become empty, as hotplug processes=20 >> might be generated at any time. >> >> Or is there an easier way? >=20 >=20 > Well if you want to increase the maximum number by ten you do: >=20 > for (i =3D 0; i < 10; i++) > up(&foo); >=20 Indeed. That will work nicely. > and similarly for decreasing the limit. That will involve doing down()s, > which will automatically wait for the current number of threads to fall to > the desired level. >=20 Hmm. Really? I mean, is there really an effect when the semaphore=20 waitqueue is active? AFAICS down() on an semaphore with active waitqueue will always set the=20 counter to -1; and as we don't have any thread corresponding to the=20 down() we just issued the semaphore will continue starting threads once=20 an up() is executed. Probably not making myself clear here ... The problem (from my point of view) with semaphores is that we don't=20 have an direct counter of the number of processes waiting on that=20 semaphore to become free. We do have a counter for the number of=20 processes which are allowed to use the semaphore concurrently (namely=20 ->count), but the number of waiting processes must be gathered=20 indirectly by the number of entries in the waitqueue. Given enough processes in the waitqueue, the number of currently running=20 processes effectively determines the number of processes to be started. And as those processes are already running, I don't see an effective=20 procedure how we could _reduce_ the number of processes to be started. > But I don't really see a need to tune this on the fly - probably the worse > problem occurs during bootup when the operator cannot perform tuning. >=20 Och aye, there is. If the calling parameters to call_usermodehelper are=20 stored temporarily, you can allow for the call to return immediately=20 when not enough resources are available. This way, it is even possible=20 to stop khelper processes altogether (and effectively queueing all=20 events) and re-enable the khelper processes at a later stage. or you can throttle the number of khelper processes to some insanely=20 small number (my test here runs with khelper_max=3D1), which lets you test = your boot scripts for race conditions resp. hotplug awareness quite nicely. > So a __setup parameter seems to be the best way of providing tunability. = > Initialise the semaphore in usermodehelper_init(). >=20 Which is what I've done. THX Andrew, your feedback was _very_ welcome. Will wrap up a new patch. Cheers, Hannes --=20 Dr. Hannes Reinecke hare@suse.de SuSE Linux AG S390 & zSeries Maxfeldstra=DFe 5 +49 911 74053 688 90409 N=FCrnberg http://www.suse.de ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=CCk _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel