From: Stephen Williams <steve@icarus.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [RFC] /sbin/hotplug multiplexor
Date: Fri, 18 Apr 2003 02:08:44 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-105063177113499@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-105034677627168@msgid-missing>
Stephen Williams wrote:
> david-b@pacbell.net said:
>
>>How often do you connect a new USB or PCI device? If it takes a full
>>second to react, that's OK; and Linux is usually faster than that.
>
>
> When I was running on a 66MHz system w/ 128Meg RAM, it took on
> the order of 30 seconds to get around to invoking fxload. The
> initial execute of /sbin/hotplug may be quick, but that script
> sure takes a while to run. I think performance is an issue.
david-b@pacbell.net said:
> Systems that are "under-powered" have other tools available, like
> having /sbin/hotplug be a custom C program. Hmm, where have I heard
> of such a thing before, Greg? :)
OK, temper-tantrum follows...
A CPU is pegged in my K-WizzyHz workstation doing a Verilog simulation
or some image processing, and I hotplug a camera to get more images.
Now /sbin/hotplug starts running a bunch of processes, causing a lot
of kernel activity to dispatch the hotplug event to umpteen processes,
fiddling with a zillion minor configuration files and subscripts until
it gets figured out and a kernel module for a USB mass storage device
is loaded, all the while thrashing caches and invoking page allocations-
deallocations, and disrupting the background task, not to mention the
desktop.
A ridiculous burden is a ridiculous burden no matter how fast the
host system. I want my super-system doing *my* work, not spending
barrels of mips and I/O cycles picking its nose.
I used my earlier mentioned 66MHz system to receive high resolution
8.5x11" color images, several images per second; yet plugging in a
minor USB device was a major disruption for half a minute. Something
is very wrong with this picture.
Incidentally, with REMOVER support, unplugging that minor device
was nearly instantaneous on this "under-powered" machine. So getting
the event to a process and dispatching it should be fast. It's been
a while since I've been in the guts of the hotplug scripts, but my
impression remains that they are in desperate need of diet, even
for the normal case.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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
next prev parent reply other threads:[~2003-04-18 2:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 18:59 [RFC] /sbin/hotplug multiplexor Greg KH
2003-04-14 19:16 ` Oliver Neukum
2003-04-14 19:54 ` Greg KH
2003-04-14 20:09 ` Oliver Neukum
2003-04-14 20:33 ` Greg KH
2003-04-14 21:11 ` Oliver Neukum
2003-04-14 21:24 ` Kevin P. Fleming
2003-04-14 21:30 ` Greg KH
2003-04-14 21:34 ` Greg KH
2003-04-14 21:43 ` Oliver Neukum
2003-04-14 21:45 ` Robert Love
2003-04-14 21:52 ` Greg KH
2003-04-14 22:19 ` Oliver Neukum
2003-04-14 22:21 ` Greg KH
2003-04-14 22:44 ` Greg KH
2003-04-15 19:59 ` David Brownell
2003-04-16 16:01 ` Stephen Williams
2003-04-17 23:27 ` David Brownell
2003-04-18 2:08 ` Stephen Williams [this message]
2003-04-18 22:32 ` Greg KH
2003-04-18 23:10 ` Stephen Williams
2003-04-18 23:16 ` David Brownell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-105063177113499@msgid-missing \
--to=steve@icarus.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).