All of lore.kernel.org
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2003-04-18  2:08 UTC|newest]

Thread overview: 41+ 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
  -- strict thread matches above, loose matches on Subject: below --
2003-04-14 19:00 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:34             ` Greg KH
2003-04-14 21:45             ` Robert Love
2003-04-15 18:17               ` Frank van Maarseveen
2003-04-15 19:59               ` David Brownell
2003-04-14 21:30           ` Greg KH
2003-04-14 21:43             ` Oliver Neukum
2003-04-14 21:52               ` Greg KH
2003-04-14 22:19                 ` Oliver Neukum
2003-04-14 22:44                   ` Greg KH
2003-04-14 22:04 Arnd Bergmann
2003-04-14 22:21 ` Greg KH
2003-04-14 22:23   ` Arnd Bergmann

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.