On 2015-12-08 at 23:50 ron minnich <[email protected]> wrote:
> I found the comment placement a little confusing:
> /* If you use pcpui again, reread it, since you might have migrated
> */
> + disable_irq();
> proc_restartcore();
> }
>
> Do you want the comment after the disable_irq()?
The comment is meant to go right after prep_syscalls, since that is the
point where we'd potentially block and need a new pcpui.
> Do we need to use an atomic_read for stuff like this? How smart is our
> compiler?
I think we don't need it, since pcpui is generated from core_id(),
which is an asm volatile. Unlike our TLS problems in userspace, in the
kernel the compiler doesn't know (or shouldn't!) that we are using GS
for the core_id.
So any repeated core_id() call will generate a new core_id() read.
Something like this:
int x = core_id();
printx("%d", x);
x = core_id();
printx("%d", x);
x = core_id();
printx("%d", x);
x = core_id();
printx("%d", x);
generates 4 core_id() calls in the asm.
But yeah, this is dangerous stuff.
> Although I assume the kthread is known to be locked at this point?
>
> +static inline bool is_ktask(struct kthread *kthread)
> +{
> + return kthread->flags & KTH_IS_KTASK;
> +}
Yeah, I think so. My intent was for this to be a synchronous
operation: either the kthread/ktask is not running (i.e. we're about to
launch it or block it) or the kthread itself is asking. So there
shouldn't be any races with that flag changing.
> + /* Pretend that we blocked while filing this page. This catches a
> lot of
> + * bugs. It does slightly slow down the kernel, but it's only when
> filling
> + * the page cache, and considering we are using a RAMFS, you
> shouldn't
> + * measure things that actually rely on KFS's performance. */
> + kthread_usleep(1000);
> ah, hmm.
> I guess this is ok as kfs is on its way out?
Yeah, that's my thought. Once we start running a real FS (or say
something over a 9p mount), we will run into issues with the FS
blocking. It's better to start catching those now. Also, any perf
measurement with KFS involved in the critical path is a bad benchmark
for Akaros.
> Pretty much LGTM otherwise. I can't claim to understand all the
> implications, however :-)
Likewise. =) Even if nothing is broken, I'll probably come back to
these commit messages and try to figure out what is going on.
Barret
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
