Date: Mon, 24 Nov 2014 15:26:21 +0900
From: Masao Uebayashi <uebay...@gmail.com>
(I'm trying, but I can't follow up all mails soon, because I need more
than x2 energy & time to write English than you.)
I understand! I will keep this one brief.
On Mon, Nov 24, 2014 at 12:12 PM, Taylor R Campbell
<campbell+netbsd-tech-k...@mumble.net> wrote:
> Can you (or ozaki-r@, whose earlier patch I missed until now) explain
> specifically what this accomplishes? I have two guesses about the
> primary goal of this change: either
>
> (a) to obviate the need to run if_watchdog/if_slowtimo callbacks
> inside IFNET_FOREACH, or
I was thinking of this first.
OK!
> In case (a), what might an interface do in an if_watchdog/if_slowtimo
> callback that is safe in a callout but not safe inside a pserialized
> reader? Is it simply that it's sort-of-kind-of OK for a callout to
> block a little, but absolutely not OK for a pserialized reader to
> block and thus switch?
I have believed that pserialize(9) reader-side is a critical section.
pserialize(9) relies on scheduler to notify that readers have passed
throught those pserialize(9) protected code paths, by calling
pserialize_switchpoint() from mi_switch(). This obviously implies
that threads can't sleep from within those pserialize(9) protected
code paths. Otherwise that notification has a different meaning.
Yes, that's right.
Ideally, we should avoid blocking much in callouts too.
I think pserialize_read_{enter,exit}() should explicitly call
KPREEMPT_{DISABLE,ENABLE}(), as is done in percpu_{getref,putref}().
Not necessary -- splsoftserial is sufficient to prevent switching, and
is necessary to block the pserialize cross-call until the reader is
finished.
