On 9/24/20 10:27 AM, pet...@infradead.org wrote:
> So my current todo list is:
>
> - Change RT PULL
> - Change DL PULL
> - Add migrate_disable() tracer; exactly like preempt/irqoff, except
>measuring task-runtime instead of cpu-time.
> - Add a mode that measures actual interference.
> -
On Thu, 24 Sep 2020 19:55:10 +0200
Thomas Gleixner wrote:
> On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote:
> > On Thu, 24 Sep 2020 08:57:52 +0200
> > Thomas Gleixner wrote:
> >
> >> > Now as for migration disabled nesting, at least now we would have
> >> > groupings of this, and perhaps
On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote:
> On Thu, 24 Sep 2020 08:57:52 +0200
> Thomas Gleixner wrote:
>
>> > Now as for migration disabled nesting, at least now we would have
>> > groupings of this, and perhaps the theorists can handle that. I mean,
>> > how is this much different
On Thu, Sep 24, 2020 at 09:51:38AM -0400, Steven Rostedt wrote:
> > It turns out, that getting selected for pull-balance is exactly that
> > condition, and clearly a migrate_disable() task cannot be pulled, but we
> > can use that signal to try and pull away the running task that's in the
> >
On Thu, 24 Sep 2020 14:42:41 +0200
Peter Zijlstra wrote:
> On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote:
> > Anyway, instead of blocking. What about having a counter of number of
> > migrate disabled tasks per cpu, and when taking a migrate_disable(), and
> > there's
> >
On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote:
> Anyway, instead of blocking. What about having a counter of number of
> migrate disabled tasks per cpu, and when taking a migrate_disable(), and
> there's
> already another task with migrate_disabled() set, and the current task has
On Thu, 24 Sep 2020 08:57:52 +0200
Thomas Gleixner wrote:
> > Now as for migration disabled nesting, at least now we would have
> > groupings of this, and perhaps the theorists can handle that. I mean,
> > how is this much different that having a bunch of tasks blocked on a
> > mutex with the
On Wed, Sep 23, 2020 at 11:52:51AM -0400, Steven Rostedt wrote:
> On Wed, 23 Sep 2020 10:40:32 +0200
> pet...@infradead.org wrote:
>
> > However, with migrate_disable() we can have each task preempted in a
> > migrate_disable() region, worse we can stack them all on the _same_ CPU
> > (super
On Wed, Sep 23 2020 at 17:12, Steven Rostedt wrote:
> On Wed, 23 Sep 2020 22:55:54 +0200
> Then scratch the idea of having anonymous local_lock() and just bring
> local_lock in directly? Then have a kmap local lock, which would only
> block those that need to do a kmap.
That's still going to end
On Wed, 23 Sep 2020 22:55:54 +0200
Thomas Gleixner wrote:
> > Perhaps make migrate_disable() an anonymous local_lock()?
> >
> > This should lower the SHC in theory, if you can't have stacked migrate
> > disables on the same CPU.
>
> I'm pretty sure this ends up in locking hell pretty fast and
On Wed, Sep 23 2020 at 11:52, Steven Rostedt wrote:
> On Wed, 23 Sep 2020 10:40:32 +0200
> pet...@infradead.org wrote:
>
>> However, with migrate_disable() we can have each task preempted in a
>> migrate_disable() region, worse we can stack them all on the _same_ CPU
>> (super ridiculous odds,
On Wed, 23 Sep 2020 10:40:32 +0200
pet...@infradead.org wrote:
> However, with migrate_disable() we can have each task preempted in a
> migrate_disable() region, worse we can stack them all on the _same_ CPU
> (super ridiculous odds, sure). And then we end up only able to run one
> task, with the
On Mon, Sep 21 2020 at 21:27, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote:
>> On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>> Maybe we really *could* call this new kmap functionality something
>> like "kmap_percpu()" (or maybe "local" is good enough),
On Wed, Sep 23 2020 at 10:40, peterz wrote:
> Right, so I'm concerned. migrate_disable() wrecks pretty much all
> Real-Time scheduler theory we have, and PREEMPRT_RT bringing it in is
> somewhat ironic.
It's even more ironic that the approach of PREEMPT_RT has been
'pragmatic ignorance of theory'
On Wed, Sep 23 2020 at 12:19, peterz wrote:
> On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
>> Alternatively this could of course be solved with per CPU page tables
>> which will come around some day anyway I fear.
>
> Previously (with PTI) we looked at making the entire kernel
On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
> Alternatively this could of course be solved with per CPU page tables
> which will come around some day anyway I fear.
Previously (with PTI) we looked at making the entire kernel map per-CPU,
and that takes a 2K copy on
On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote:
> > On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
> >>
> >> If a task is migrated to a different CPU then the mapping address will
> >> change which will explode in
On Sat, Sep 19, 2020 at 06:39:06PM +0100, Matthew Wilcox wrote:
> On Sat, Sep 19, 2020 at 10:18:54AM -0700, Linus Torvalds wrote:
> > On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
> > >
> > > this provides a preemptible variant of kmap_atomic & related
> > > interfaces. This is achieved
On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote:
> On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>>
>> If a task is migrated to a different CPU then the mapping address will
>> change which will explode in colourful ways.
>
> Right you are.
>
> Maybe we really *could* call this new
On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>
> If a task is migrated to a different CPU then the mapping address will
> change which will explode in colourful ways.
Heh.
Right you are.
Maybe we really *could* call this new kmap functionality something
like "kmap_percpu()" (or
On Sun, Sep 20 2020 at 10:42, Linus Torvalds wrote:
> On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote:
>>
>> I think the more obvious solution is to split the whole exercise:
>>
>> schedule()
>> prepare_switch()
>> unmap()
>>
>> switch_to()
>>
>> finish_switch()
>>
On Sun, Sep 20, 2020 at 10:42 AM Linus Torvalds
wrote:
>
> Yeah, that looks much easier to explain. Ack.
Btw, one thing that might be a good idea at least initially is to add
a check for p->kmap_ctrl.idx being zero at fork, exit and maybe
syscall return time (but that last one may be too
On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote:
>
> I think the more obvious solution is to split the whole exercise:
>
> schedule()
> prepare_switch()
> unmap()
>
> switch_to()
>
> finish_switch()
> map()
Yeah, that looks much easier to explain. Ack.
On Sun, Sep 20 2020 at 09:57, Linus Torvalds wrote:
> On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote:
> Btw, looking at the stack code, Ithink your new implementation of it
> is a bit scary:
>
>static inline int kmap_atomic_idx_push(void)
>{
> - int idx =
On Sun, Sep 20 2020 at 10:23, Daniel Vetter wrote:
> On Sun, Sep 20, 2020 at 08:23:26AM +0200, Thomas Gleixner wrote:
>> On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote:
>> > On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote:
>> >> I think it should be the case, but I want to double check:
On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote:
>
> Actually most usage sites of kmap atomic do not need page faults to be
> disabled at all.
Right. I think the pagefault disabling has (almost) nothing at all to
do with the kmap() itself - it comes from the "atomic" part, not the
"kmap"
On Sun, Sep 20 2020 at 08:41, Thomas Gleixner wrote:
> On Sat, Sep 19 2020 at 10:18, Linus Torvalds wrote:
>> Maybe I've missed something. Is it because the new interface still
>> does "pagefault_disable()" perhaps?
>>
>> But does it even need the pagefault_disable() at all? Yes, the
>> *atomic*
On Sun, Sep 20, 2020 at 08:23:26AM +0200, Thomas Gleixner wrote:
> On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote:
> > On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote:
> >> I think it should be the case, but I want to double check: Will
> >> copy_*_user be allowed within a kmap_temporary
On Sat, Sep 19 2020 at 10:18, Linus Torvalds wrote:
> On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
>>
>> this provides a preemptible variant of kmap_atomic & related
>> interfaces. This is achieved by:
>
> Ack. This looks really nice, even apart from the new capability.
>
> The only
On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote:
> On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote:
>> I think it should be the case, but I want to double check: Will
>> copy_*_user be allowed within a kmap_temporary section? This would
>> allow us to ditch an absolute pile of slowpaths.
>
On Sat, Sep 19, 2020 at 10:39 AM Matthew Wilcox wrote:
>
> My concern with that is people might use kmap() and then pass the address
> to a different task. So we need to audit the current users of kmap()
> and convert any that do that into using vmap() instead.
Ahh. Yes, I guess they might do
On Sat, Sep 19, 2020 at 10:18:54AM -0700, Linus Torvalds wrote:
> On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
> >
> > this provides a preemptible variant of kmap_atomic & related
> > interfaces. This is achieved by:
>
> Ack. This looks really nice, even apart from the new capability.
On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
>
> this provides a preemptible variant of kmap_atomic & related
> interfaces. This is achieved by:
Ack. This looks really nice, even apart from the new capability.
The only thing I really reacted to is that the name doesn't make sense
to
On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote:
>
> On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner wrote:
> >
> > First of all, sorry for the horribly big Cc list!
> >
> > Following up to the discussion in:
> >
> > https://lore.kernel.org/r/20200914204209.256266...@linutronix.de
> >
>
On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner wrote:
>
> First of all, sorry for the horribly big Cc list!
>
> Following up to the discussion in:
>
> https://lore.kernel.org/r/20200914204209.256266...@linutronix.de
>
> this provides a preemptible variant of kmap_atomic & related
>
First of all, sorry for the horribly big Cc list!
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de
this provides a preemptible variant of kmap_atomic & related
interfaces. This is achieved by:
- Consolidating all kmap atomic implementations
36 matches
Mail list logo
