From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Mon, 25 Oct 2004 17:07:50 +0000 Subject: Re: udev hangs under high loads Message-Id: <20041025170750.GA31117@vrfy.org> List-Id: References: <20041023054119.GA11915@kroah.com> In-Reply-To: <20041023054119.GA11915@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Mon, Oct 25, 2004 at 12:01:04AM -0700, Greg KH wrote: > On Sun, Oct 24, 2004 at 09:56:16PM +0200, Kay Sievers wrote: > > On Sun, Oct 24, 2004 at 09:51:01PM +0200, Marco d'Itri wrote: > > > On Oct 24, Kay Sievers wrote: > > > > > > > Just use a "normal" filesysten then and everything is fine. > > > There are many good reasons for using tmpfs for /dev, and I would be > > > very displeased if this will not be possible or practical anymore. > > > > Yes it's nice and there is still nothing wrong with tmpfs use. It's just > > a bit more space needed than before. Ever thought about much memory _every_ > > file in sysfs takes? > That being said, putting a single, small (less than a single page) file > for every device node in the system in tmpfs should not be a big deal. > Anyone have any real numbers that they are worried about? On my box with app. 800 device nodes (which should be the number of app. 90 percent of the boxes out there) tmpfs is ~3 MByte big with the files db. That's not cool, but it's a limitation of tmpfs not udev :) I personally think the complete independend and reliable operation of concurrent events is more worth than to work around a filesystem limitation with our own single-file-db implementation. The average multi-file-db file is less than 40 Bytes long now. Maybe it will grow a bit, but not much, as we only need to store the names of our created nodes and the all_partitions count. Every other information (major/minor, type) can be stat()'ed from the node itself, we don't need to store it in the db. The question is: Can we change the tmpfs implementation to store file content inline if it fits into struct shmem_inode_info. Mostly the same way symlink targets are handled today (only targets longer than 110 bytes are allocating a page). This would be much more efficient, uses minimal memory and is the fastest we can get. And it would solve all the problems, I don't have :) Thanks, Kay ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ 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