Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1362741

Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock

Show all headers | View raw

On Tue, Mar 22, 2016 at 01:20:50PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 12:32:21PM +0100, Heiko Carstens wrote:
> > On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
> 
> > > And s390 does something entirely vile, no idea what.
> > 
> > For the two s390 usages tsk equals current. So it could be easily replaced
> > with set_current_state().
> 
> Hmm indeed, I only saw tsk = find_task_by_pid_ns() and didn't look
> further, but you do indeed have an assertion later that ensures task ==
> current.
> 
> I still don't get that code though; why would you set the current task
> state to UNINTERRUPTIBLE, also set need_resched, but then not call
> schedule() at all.
> 
> Clearly something magical is going on and its not clear.

The mechanism of our pfault code: if Linux is running as guest, runs a user
space process and the user space process accesses a page that the host has
paged out we get a pfault interrupt.

This allows us, within the guest, to schedule a different process. Without
this mechanism the host would have to suspend the whole virtual CPU until
the page has been paged in.

So when we get such an interrupt then we set the state of the current task
to uninterruptible and also set the need_resched flag. Both happens within
interrupt context(!). If we later on want to return to user space we
recognize the need_resched flag and then call schedule().
It's not very obvious how this works...

Of course we have a lot of additional fun with the completion interrupt (->
host signals that a page of a process has been paged in and the process can
continue to run). This interrupt can arrive on any cpu and, since we have
virtual cpus, actually appear before the interrupt that signals that a page
is missing.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Davidlohr Bueso <dave@stgolabs.net> - 2016-03-21 19:20 +0100
  Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Peter Zijlstra <peterz@infradead.org> - 2016-03-22 11:30 +0100
    Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-03-22 12:50 +0100
      Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Peter Zijlstra <peterz@infradead.org> - 2016-03-22 13:30 +0100
        Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-03-22 14:30 +0100
          Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Peter Zijlstra <peterz@infradead.org> - 2016-03-22 15:00 +0100
            Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-03-22 15:50 +0100
              Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Peter Zijlstra <peterz@infradead.org> - 2016-03-22 17:50 +0100
                Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-03-22 22:50 +0100
    Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Davidlohr Bueso <dave@stgolabs.net> - 2016-03-25 03:40 +0100

csiph-web