> For eg: if a clock interrupt from userland got deferred as pending, even
> if it came in from userland (is this possible ?), because the current
> spl level was at, say, SPL_HIGH, it now seems to be the case that the
> system accounts for the delayed execution by charging the *entire* time
> (from the last hardclock() inclusive of whatever was executing at
> SPL_HIGH, to the system and not the userland process, thus charging the
> time interval between when the last hardclock() was called, and when it
> was actually serviced, to the system instead of the user process that
> was originally interrupted.
>
> To emphasise my point, I've added a patch below that I think should
> reflect the accounting correctly.
>
> I'm not sure I've understood this correctly, so I'd appreciate it if
> someone who has a good understanding of this would be able to comment.
>
> Many Thanks,
>
> Cherry
>
>
>
> --- kern_clock.c.~1.138.~ 2018-09-21 11:28:02.792675611 +0000
> +++ kern_clock.c 2018-10-16 12:06:38.753987323 +0000
> @@ -352,6 +352,10 @@
> }
>
> if (CLKF_USERMODE(frame)) {
> + if (p == NULL) { /* Account deferred clock ticks to
> current user. */
> + p = l->l_proc;
> + mutex_spin_enter(&p->p_stmutex);
> + }
> KASSERT(p != NULL);
> if ((p->p_stflag & PST_PROFIL) && profsrc ==
> PROFSRC_CLOCK)
> addupc_intr(l, CLKF_PC(frame));
i don't believe this can happen. if it does, then something
else is horribly wrong and should be fixed instead.
eg, if i'm in usermode, then i can't be the idle thread, so
p should always be valid. (usermode can also never be at any
IPL besides 0, with it being an outright bug.)
what problem are you actually trying to solve?
.mrg.
