Re: [ANNOUNCE] udev 0.1 release

[Lars Marowsky-Bree]

On 2003-04-11T16:31:47,
   Steven Dake <[e-mail]> said:

> What I actually mean is:
> disk is in the bus/loop/etc, powered on, ready to be enumerated.
> The user then tells the OS "please insert the disk"  This is the request 
> which starts the clock.
> The point where a device entry is in /dev ready to be used stops the clock.

A bus rescan on SCSI / FC will take longer than your 20ms already.

A single hickup in the block IO involved updating the information in /dev will
break this requirement. Having to fork /sbin/hotplug will.

I've set Linux on an unloaded, rather well powered machine to heartbeat every
10ms and checked in what intervals it actually did - mostly it was 10-30ms,
but there have been exceptions for upto 200-1000ms. And that's for a
locked-into-memory "soft realtime", no swapping very small piece of code.

Okay, this was our latest 2.4 kernel, and it would be interesting to see
whether 2.5 does better, but still. 20ms are highly ambitious.

I'm not saying "performance" is not a high goal. Having a permanently running
daemon to talk with instead of forking all the time is certainly a very
sensible idea, and the kernel _must_ be able to cope with 4k disks being
plugged in at once.

But evidence suggests that _guaranteeing_ 20ms seems a bit over the top.

Sincerely,
    Lars Marowsky-Brée <[e-mail]>

-- 
SuSE Labs - Research & Development, SuSE Linux AG
  
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
  -- Capt. Edward A. Murphy            -- Louis Pasteur