All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
To: linux-hotplug@vger.kernel.org
Subject: Re: replace in-memory rules array with match/action token list
Date: Thu, 23 Oct 2008 14:16:02 +0000	[thread overview]
Message-ID: <49008722.8060708@tuffmail.co.uk> (raw)
In-Reply-To: <4900419F.7010405@tuffmail.co.uk>

Kay Sievers wrote:
> On Thu, Oct 23, 2008 at 13:34, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote:
>   
>> Alan Jenkins wrote:
>>     
>>>> The in-memory rule array of a common desktop distro install took:
>>>>   1151088 bytes
>>>> with the token list:
>>>>   109232 bytes tokens (6827 * 16 bytes), 71302 bytes buffer
>>>>
>>>>         
>>> Sounds great from a performance point of view.
>>>
>>> It doesn't work for me though.  My simulation takes over 5 times as
>>> long, and doesn't finish cleanly; i.e. there's still lots in
>>> /dev/.udev/queue after the cpu usage has stopped.  I'll try to track it
>>> down.
>>>
>>>       
>> Sorry - the queue is cleaned up correctly.  I was just too impatient.
>>
>> It's not a perfect test; I'm comparing
>>
>> a391f49d7f5433e6204f35331b81391c2d110309 - good ..
>> b99028c96307e729303be8f6750418979a7488b9 - bad
>>
>> which includes a few more commits, though the match/action list is
>> obviously the biggest one.
>>
>> The bad version of udevd seems to be generating two extra uevents per
>> device, in addition to the ones generated by "udevadm trigger".  That
>> is, the output of "udevadm monitor --kernel" is three times as long!
>>
>> It's not a change in udevmonitor or udevtrigger; I'm still using the
>> Ubuntu installed version of udevadm for testing.  I really don't
>> understand how this could happen.  Do you have any idea?
>>     
>
> Hmm, I don't see that here. Any rules you have, which may trigger
> uevents, and which may behave differently now?
>   grep uevent /etc/udev/rules.d/* /lib/udev/rules.d/* /dev/.udev/rules.d/*
>
> Kay
>   

Nope.

Drat, I can't reproduce that any more.  It's still takes over five times
as long, but I can't see anything unexpected happening.

I tried using strace (piped through grep 'open.*uevent".*WR').  At that
point it seemed to stop happening, even when I rebooted and ran it
without strace.

All I can think is, I must have accidentally run "udevadm trigger" twice
before I started udevd.

Baaa

(sheepishly) Alan

  parent reply	other threads:[~2008-10-23 14:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-23  9:19 replace in-memory rules array with match/action token list Alan Jenkins
2008-10-23 11:34 ` Alan Jenkins
2008-10-23 12:47 ` Kay Sievers
2008-10-23 14:16 ` Alan Jenkins [this message]
2008-10-23 14:36 ` Kay Sievers
2008-10-23 16:10 ` Alan Jenkins
2008-10-23 19:09 ` Kay Sievers

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=49008722.8060708@tuffmail.co.uk \
    --to=alan-jenkins@tuffmail.co.uk \
    --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.