[RFC] reliability and scalability

[RFC] reliability and scalability

[Chris Friesen]

I've got a couple more ideas for improving udevd, but before I go crazy
with this I wanted to get some opinions from people more experienced
than me.

First, how paranoid should we be about reliability?  Right now there is a
(low) possibility of udevd crashing with unhandled messages on its rx
buffer, thus losing one or more hotplug events.  Is this a problem?
Would people welcome a patch that closes the loop by sending an ack back
to udevsend?

Second, how many udev instances are we expecting to have outstanding at
a time?  There are a couple of places in udevd (specifically the devpath
check and the udev_done code) that with the current data structures end
up being worst case ofO(n^2).  Is this a problem?  The average user will
never have an issue, but if we suddenly plug in a few thousand disks (a
number that's been mentioned before), is it a big deal if it takes a
bit longer to add them all?  I see ways of getting around this, but
it may be overkill.

Comments, anyone?

Chris



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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

Re: [RFC] reliability and scalability

[Olaf Hering]

 On Sat, Feb 07, Chris Friesen wrote:

> Comments, anyone?

Better get rid of udevd and keep track of the latest add and remove
SEQNUMs in the database.  unlink the devnodes and symlinks before
creating new ones during add events.

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, n√úRNBERG


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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

Re: [RFC] reliability and scalability

[Kay Sievers]

On Sat, Feb 07, 2004 at 03:01:29AM -0500, Chris Friesen wrote:
> 
> I've got a couple more ideas for improving udevd, but before I go crazy
> with this I wanted to get some opinions from people more experienced
> than me.
> 
> First, how paranoid should we be about reliability?  Right now there is a
> (low) possibility of udevd crashing with unhandled messages on its rx
> buffer, thus losing one or more hotplug events.  Is this a problem?
> Would people welcome a patch that closes the loop by sending an ack back
> to udevsend?

I don't care. What you want to do with the information in udevsend?

> Second, how many udev instances are we expecting to have outstanding at
> a time?  There are a couple of places in udevd (specifically the devpath
> check and the udev_done code) that with the current data structures end
> up being worst case ofO(n^2).  Is this a problem?  The average user will
> never have an issue, but if we suddenly plug in a few thousand disks (a
> number that's been mentioned before), is it a big deal if it takes a
> bit longer to add them all?  I see ways of getting around this, but
> it may be overkill.

We may limit the size of the run_queue, and hold back the forks when to
many udev's already running.

thanks,
Kay


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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

Re: [RFC] reliability and scalability

[Greg KH]

On Sat, Feb 07, 2004 at 09:57:58AM +0100, Olaf Hering wrote:
>  On Sat, Feb 07, Chris Friesen wrote:
> 
> > Comments, anyone?
> 
> Better get rid of udevd and keep track of the latest add and remove
> SEQNUMs in the database.  unlink the devnodes and symlinks before
> creating new ones during add events.

And how would you re-order events in this situation?

No, udevd is needed.

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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

Re: [RFC] reliability and scalability

[Greg KH]

On Sat, Feb 07, 2004 at 03:01:29AM -0500, Chris Friesen wrote:
> 
> I've got a couple more ideas for improving udevd, but before I go crazy
> with this I wanted to get some opinions from people more experienced
> than me.
> 
> First, how paranoid should we be about reliability?  Right now there is a
> (low) possibility of udevd crashing with unhandled messages on its rx
> buffer, thus losing one or more hotplug events.  Is this a problem?
> Would people welcome a patch that closes the loop by sending an ack back
> to udevsend?

I would welcome this.  We really don't want to loose events.  But how
long should udevsend wait before retrying the message?  I can see this
getting messy...

> Second, how many udev instances are we expecting to have outstanding at
> a time?

As many as possible?  :)

> There are a couple of places in udevd (specifically the devpath
> check and the udev_done code) that with the current data structures end
> up being worst case ofO(n^2).  Is this a problem?  The average user will
> never have an issue, but if we suddenly plug in a few thousand disks (a
> number that's been mentioned before), is it a big deal if it takes a
> bit longer to add them all?  I see ways of getting around this, but
> it may be overkill.

This is very easy to test with scsi-debug.  I don't really think this is
a issue right now, but if you want to try improving it a bit, please do.

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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

Re: [RFC] reliability and scalability

[Olaf Hering]

 On Sat, Feb 07, Greg KH wrote:

> On Sat, Feb 07, 2004 at 09:57:58AM +0100, Olaf Hering wrote:
> >  On Sat, Feb 07, Chris Friesen wrote:
> > 
> > > Comments, anyone?
> > 
> > Better get rid of udevd and keep track of the latest add and remove
> > SEQNUMs in the database.  unlink the devnodes and symlinks before
> > creating new ones during add events.
> 
> And how would you re-order events in this situation?

What do you mean with reorder? Maybe I miss the point.


I assume the database has some locking to serialize writes (maybe even
reads).
- If an add event arrives, check if a remove event was recoreded.
  If the remove event had a higher number than this add event, record this
  add event as seen if no newer add event was seen, then exit.
  If no remove and no newer add event was seen, unlink the node and
  symlinks and recreate them. Record the current number as 'add'.
- If a remove event arrives, check if an add event was recorded.
  If the add event had a higher number, record this remove event if no
  newer remove event was seen, then exit.

Maybe something like this:

switch(action)
        case add:
                if (last.add > seqnum)
                        exit
                if (last.remove > seqnum)
                        exit
                last.add = seqnum
                unlink (node)
                mknod (node)
                if (symlink) {
                        unlink (symlink)
                        ln (node, symlink)
                }
                exit

        case remove:
                if (last.add > seqnum)
                        exit
                if (last.remove > seqnum)
                        exit
                last.remove = seqnum
                unlink (node)
                if (symlink)
                        unlink (symlink)
                exit

> No, udevd is needed.

I'm not convinced.

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, n√úRNBERG


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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

Re: [RFC] reliability and scalability

[Kay Sievers]

On Sat, Feb 07, 2004 at 03:01:29AM -0500, Chris Friesen wrote:
> 
> I've got a couple more ideas for improving udevd, but before I go crazy
> with this I wanted to get some opinions from people more experienced
> than me.
> 
> First, how paranoid should we be about reliability?

Oh, if forgot the paranoia :)

What should we do with the abstract socket.
It is open to any user, not only root.
We have to fix this!

Kay


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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

Re: [RFC] reliability and scalability

[Greg KH]

On Sat, Feb 07, 2004 at 09:20:06PM +0100, Olaf Hering wrote:
>  On Sat, Feb 07, Greg KH wrote:
> 
> > On Sat, Feb 07, 2004 at 09:57:58AM +0100, Olaf Hering wrote:
> > >  On Sat, Feb 07, Chris Friesen wrote:
> > > 
> > > > Comments, anyone?
> > > 
> > > Better get rid of udevd and keep track of the latest add and remove
> > > SEQNUMs in the database.  unlink the devnodes and symlinks before
> > > creating new ones during add events.
> > 
> > And how would you re-order events in this situation?
> 
> What do you mean with reorder? Maybe I miss the point.

You have to order the events that come in by the seqnum, right?

So if you get a new one, you have to place it in the proper place amoung
all other outstanding events.

> Maybe something like this:
> 
> switch(action)
>         case add:
>                 if (last.add > seqnum)
>                         exit
>                 if (last.remove > seqnum)
>                         exit

exit?  Then do what?  Sit and spin?  You need something persistant to
stick around and figure out what to do next.

And udev is not big at _all_.  On my box it's the tiniest thing running
by a _large_ ammount:

$ size /sbin/udevd 
   text    data     bss     dec     hex filename
   5205      52      20    5277    149d /sbin/udevd

It's still smaller than /bin/true :)

$ size /bin/true 
   text    data     bss     dec     hex filename
   8623     724       0    9347    2483 /bin/true


thanks,

greg k-h


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
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