re: Time accounting on statclock()

[matthew green <mrg%eterna.com.au@localhost>]

> 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.