From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Jenkins Date: Sat, 25 Oct 2008 17:19:37 +0000 Subject: Re: [PATCH] udevd: fix WAIT_FOR_SYSFS Message-Id: <49035529.5080906@tuffmail.co.uk> List-Id: References: <4900C46A.7070501@tuffmail.co.uk> In-Reply-To: <4900C46A.7070501@tuffmail.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Alan Jenkins wrote: > Kay Sievers wrote: > >> On Thu, Oct 23, 2008 at 21:56, Alan Jenkins wrote: >> >> >>> Kay Sievers wrote: >>> >>> >>>> On Thu, Oct 23, 2008 at 21:03, Kay Sievers wrote: >>>> >>>> >>>>> On Thu, Oct 23, 2008 at 20:37, Alan Jenkins wrote: >>>>> >>>>> >>>>> >>>>>> The wait should be ordered after matching KERNEL, ENV, etc. >>>>>> but before ATTR. >>>>>> >>>>>> Without this, WAIT_FOR_SYSFS rules will be applied unconditionally >>>>>> to all events. >>>>>> >>>>>> >>>>>> >>>>> Ah, nice! Thanks for finding that out. I do not have any of theses >>>>> rules left, as there are currently no know issues with recent kernels. >>>>> :) Applied. >>>>> >>>>> >>>> Oh, now that I expect it works for you without the long delay. :) How >>>> does is compare? Is it still slower? >>>> >>>> >> >> >>> No, that fixed it. The network interface rename problem seems to have >>> gone as well (!). >>> >>> I just tested it on my desktop. oprofile says it now _reduces_ cpu >>> cycles in udevd by 10%. Not big enough to show up in time(1), but not >>> bad! And it should help more on the EeePC, which has a less lavish cpu >>> cache. >>> >>> >> Sounds good. I've changed a few other things, which might make things faster: >> >> We cache the results of getpwnam/getgrnam() during rules parse time, >> some of the rules files I have here have ~700 rules with GROUP="..." >> keys ... >> >> We check at parse time, if we need to call fnmatch() for a key, or can >> just go with the much cheaper strcmp(). That seems to make a real >> difference with the large rules files I have. >> >> > > Nice. > > >> Also the snprintf() that was used compose the buffer to pass the event >> to a socket was _very_ expensive. We just use strlcpy() now and cache >> the result for the next RUN+="socket:" call. >> >> > > I might adapt that for udev-exec. > > But I think it needs a flag like envp_uptodate, no? > And for bonus points... udev_device_get_properties_envp() could return pointers into this buffer, instead of allocating individual strings on the heap. Alan