Re: [PATCH v7 07/11] arch/x86: enable task isolation functionality

[Thomas Gleixner]

On Tue, 29 Sep 2015, Andy Lutomirski wrote:
> On Tue, Sep 29, 2015 at 10:42 AM, Chris Metcalf <cmetcalf@xxxxxxxxxx> wrote:
> > Scheduling a timer for 10 minutes away is typically done by
> > scheduling timers for the max timer granularity (which could
> > be just a few seconds) and then waking up a couple of hundred
> > times between now and now+10 minutes.  Doing this breaks
> > the task isolation guarantee, so we can't return to userspace
> > while something like that is pending.  You'd have to do it
> > by polling in userspace to avoid the unexpected interrupts.
> >
> 
> Really?  That sucks.  Hopefully we can fix it.

Well. If there is a timer pending, then what do you want to fix? If
the hardware does not allow to program a long out expiry time, then
the kernel cannot do anything about it.

That depends on the timer hardware, really. PIT can do ~50ms, HPET
~3min, APIC timer ~32sec, TSC deadline timer ~500years.

> > I suppose if your hardware supported it, you could imagine
> > a mode where userspace can request an alarm a specific
> > amount of time in the future, and the task isolation code
> > would then ignore an alarm that was going off at that
> > specific time.

Ignore in what way?

> > But I'm not sure what hardware does support
> > that (I know tile uses the "few seconds and re-arm" model),
> > and it seems like a pretty corner use-case.  We could
> > certainly investigate adding such support later, but I don't see
> > it as part of the core value proposition for task isolation.

I'm really not following here. If user space requested that timer, WHY
on earth do you want to spin in the kernel until it fired? That's
insane.
 
> Intel chips Sandy Bridge and newer certainly support this. Other chips
> might support it as well.  Whether the kernel is able to program the
> TSC deadline timer like that is a different question.

If the next expiry is out 100 years then we will happily program it
for that expiry time.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/